Potential Network SIG

[Simon Marlow]

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<marlowsd at gmail.com>
>> 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