Potential Network SIG
marlowsd at gmail.com
Wed Aug 26 03:47:01 EDT 2009
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>
>> 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.
More information about the Libraries