runtime fusion for Data.ByteString.cons ?

[Donald Bruce Stewart]

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