Re: Potential Network SIG

On 25/08/2009 22:28, Duncan Coutts wrote:

On Tue, 2009-08-25 at 09:18 -0700, Bryan O'Sullivan wrote:

...

On Tue, Aug 25, 2009 at 5:03 AM, Simon Marlow wrote:

Right now, that means making Handles from Sockets (which is something the current network library provides). And then you use the bytestring library to write bytestrings to the Handle. In the future we'll have a way to write text to a Handle too.

I remember seeing notes about the new I/O code being about 20-25% slower than the old, due to support for character set transcoding. If my recollection is correct, would that hold true for writing ByteStrings, too? (Yes, I'm somewhat performance obsessed.)

As far as I know the only slow down is when there is actual text decoding going on, ie not for ByteString I/O.

Right - and when I measured the final version, it was actually faster than the old version, but only on x86-64 (for reasons unknown). This was measuring hPutStr and hGetContents though, which if you are performance-conscious you wouldn't be using anyway. Bytestring I/O to Handles bypasses the encoding/decoding layer, and if the I/O is big enough it also bypasses the intermediate buffer and writes the bytes directly from the Bytestring. All this is unchanged relative to the old I/O library in GHC 6.10. Still, I would expect Handles to have a performance penalty for doing lots of small writes, due to the overhead of taking the lock, various exception handlers and checking whether the Char buffer needs to be flushed. If you need to do lots of small writes then you'd need to go to a lower layer or add another layer of buffering (as GHC does - see compiler/utils/BufWrite.hs in the GHC sources).

Simon has promised to explain all in his upcoming talk at the Haskell Implementers' Workshop. :-)

That will also be the obvious time to discuss what a new public I/O interface might look like. There's lots of fun new machinery in GHC's I/O system but we need to talk about public APIs.

Definitely. Cheers, Simon