[Haskell-cafe] Ready for testing: Unicode support for Handle I/O

John Goerzen jgoerzen at complete.org
Tue Feb 3 18:39:43 EST 2009


On Tue, Feb 03, 2009 at 10:56:13PM +0000, Duncan Coutts wrote:
> > > Thanks to suggestions from Duncan Coutts, it's possible to call
> > > hSetEncoding even on buffered read Handles, and the right thing
> > > happens.  So we can read from text streams that include multiple
> > > encodings, such as an HTTP response or email message, without having
> > > to turn buffering off (though there is a penalty for switching
> > > encodings on a buffered Handle, as the IO system has to do some
> > > re-decoding to figure out where it should start reading from again).
> > 
> > Sounds useful, but is this the bit that causes the 30% performance hit?
> 
> No. You only pay that penalty if you switch encoding. The standard case
> has no extra cost.

I'm confused.  I thought the standard case was conversion to the
system's local encoding?  How is that different than selecting the
same encoding manually?

There always has to be *some* conversion from a 32-bit Char to the
system's selection, right?

What exactly do we have to do to avoid the penalty?

> No, I think that's 30% for latin1. The cost is not really the character
> conversion but the copying from a byte buffer via iconv to a char
> buffer.

Don't we already have to copy between a byte buffer and a char buffer,
since read() and write() use a byte buffer?

> > 30% slower is a big deal, especially since we're not all that speedy now.
> 
> Bear in mind that's talking about the [Char] interface, and nobody using
> that is expecting great performance. We already have an API for getting

Yes, I know, but it's still the most convenient interface, and making
it suck more isn't cool -- though there are certainly big wins here.

-- John



More information about the Haskell-Cafe mailing list