ByteString I/O Performance

[Stefan O'Rear]

On Mon, Sep 03, 2007 at 07:11:45AM +0200, Tomasz Zielonka wrote:
> On Mon, Sep 03, 2007 at 01:40:51AM +0200, Peter Simons wrote:
> > One way to get malloc() out of the picture would be to provide a
> > variant of hGet that takes an existing, pre-allocated buffer as an
> > argument, so that the user can allocate a ByteString once and re-use
> > it for every single hGet and hPut.
> 
> This seems dangerous. For example, consider that the ByteString can be
> referenced by some lazy computation, expecting it to contain the data
> from some earlier hGet.
> 
> > A different approach would be to try to reduce the cost for malloc()
> > by using some sort of pre-allocated pool of ByteStrings behind the
> > scenes.
> 
> I just wrote this, before I read you proposition:
> As safer alternative would be to keep a cache of pre-malloced buffers,
> populated by the ByteString finalizer. But the bookkeeping cost could
> outweight the benefit of avoiding malloc.

How are you getting these bytestrings?  Normal bytestring allocation
doesn't use malloc and doesn't use finalizers; it calls the (deceptively
named) mallocForeignPtrBytes function, which allocates a block of data
in the pinned GHC heap, nearly like any other Haskell object.

Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://www.haskell.org/pipermail/libraries/attachments/20070902/5bcfce3e/attachment.bin