[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