[Haskell-cafe] Re: [Haskell] installing streams library

Bulat Ziganshin bulat.ziganshin at gmail.com
Sun May 28 12:40:52 EDT 2006


Hello Duncan,

Sunday, May 28, 2006, 3:05:53 PM, you wrote:

>> createMemBuf does exactly this :)

> One of the areas where we found that Data.ByteString.Lazy was performing
> better than the ordinary Data.ByteString is cases like this where we do
> not know beforehand how big the buffer will be.

i like your idea of using ByteString.Lazy to implement fast and
easy-to-use i/o, although i don't think that speed will be in 10% of C :)

ghc by itself generates code that is several times slower than
gcc-generated and you can't do anything agaist this, except for
implementing everything in C. i've wriiten about this in ghc-users
list in February. for example, simple "a[i]=b[i]+c[i]" floating-point
loop works 20 times slower

but, nevertheless, i think that this is a great idea - much faster
than String-based hGetContents. it should help in numerous programs
that need fast-and-dirty text processing, although it needs further
development of library in order to implement for LazyByteString full
String-like interface

> If you have to use a single contiguous buffer then it involves guessing
> and possible reallocation. With a 'chunked' representation like
> ByteString.Lazy it's not a problem as we just allocate another chunk and
> start to fill that.

> Obvious example include concat and getContents.

> Would the same make sense for a MemBuf stream? Why does it need to be a
> single large buffer? Couldn't it be a list of buffers?

i also had this idea and it can be implemented in 1 day, i think (when
someone will need this). but this is not for Jeremy, he need a
contiguous buffer for interfacing with DBD. btw, it's better to use
UArray instead of list 



-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin at gmail.com



More information about the Haskell-Cafe mailing list