claus.reinke: > >On Nov 19, 2006, at 11:54 AM, Claus Reinke wrote: > >>I noticed that ByteString is drastically slower than String if I use > >>cons a lot. according to the source, that is expected because of > >>the memcpy for the second parameter. > > > >Have you considered constructing your strings with unfoldr? It > >should be able to handle most (all?) of your string producing > >functions efficiently. > > old habits die hard - I still underappreciate unfold;-) > > perhaps I should expand my habits to include unfold more often, > but in this case, I was interested in the performance of naively > recursive ByteString programming. and the cons performance > was the very first thing I noticed, so I tried to do something > about it. > > I guess I got con(s)fused by the two branches of Data.ByteString: > since it is part of base since ghc 6.6, I thought that pulling from > the ghc/libraries darcs repository would give me the latest and > greatest Data.ByteString, as described in the string rewriting > paper. the lack of Yields et al should have tripped me up.. > > what is the plan for that branch? and if there are issues that > prevent an update, shouldn't they be mentioned on the > Data.ByteString page? > > claus
Of course, you can also use stream-based ByteStrings right now, you just have to remove the Data.ByteString* dirs from base before you build, and then install the unstable fps branch via Cabal. -- Don _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users