ByteString I/O Performance
seth at cql.com
Mon Sep 3 00:08:06 EDT 2007
From: Donald Bruce Stewart [mailto:dons at cse.unsw.edu.au]
Sent: Monday, September 03, 2007 12:03 AM
To: Seth Kurtzberg
Cc: libraries at haskell.org
Subject: Re: ByteString I/O Performance
> -----Original Message-----
> From: libraries-bounces at haskell.org [mailto:libraries-bounces at haskell.org]
On Behalf Of Bryan O'Sullivan
> Sent: Sunday, September 02, 2007 11:23 PM
> To: Peter Simons
> Cc: libraries at haskell.org
> Subject: Re: ByteString I/O Performance
> 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 is already quite easy to do. See unsafeUseAsCStringLen in
> Data.ByteString.Base, and hGetBuf in System.IO.
> Is it possible without resorting to an unsafeXXX function?
They're all 'unsafe' for different reasons :)
The question should be: why is this unsafe?
(It's unsafe because it doesn't copy the C string, so you need to have a
side condition that the string isn't modified by C).
OK. Assume that I'm not doing any C coding, so that the only C code that is
invoked is called from within the implementation (in this case the
implementation of System.IO). Can I assume that no implementation code
modifies the string? In other words, is it valid to assume that the side
condition is never violated so long as I don't violate the side condition in
my own C code (if any)?
More information about the Libraries