runtime fusion for Data.ByteString.cons ?

Claus Reinke claus.reinke at
Sun Nov 19 19:54:17 EST 2006

> 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?


More information about the Glasgow-haskell-users mailing list