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?

Sometime before January I expect to tag and release fps 0.9 (with stream
fusion). It will then be merged into the base library, and be available
with the next GHC release.

The api should be identical to the currrent fps 0.8 in the base library,
just faster, since its using stream fusion instead of old-style
functional array fusion.

-- Don