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