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:[EMAIL PROTECTED] _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
