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@gmail.com