[Haskell-cafe] Speed of character reading in Haskell

ok ok at cs.otago.ac.nz
Sun Sep 9 22:09:27 EDT 2007


On 10 Sep 2007, at 11:49 am, Neil Mitchell wrote:
> Buffering, blocks and locks.
>
> Buffering: getChar demands to get a character now, which pretty much
> means you can't buffer.


Eh what?  getchar() in C "demands to get a character now", which is
fully compatible with as much buffering as you want.   In fact,
looking at the GHC 6.6 sources, I see that getChar -> hGetChar which
*does* do buffering.
>
> Blocks: getContents reads blocks at a time from the underlying
> library, whereas getChar has to do one character at a time.

Again, getchar() in C *returns* one character at a time, but gets
oodles of character from the underlying library (read(), as it happens).
As noted above, GHC 6.6 *does* read blocks from the underlying library.

>
> Locks: getChar has to acquire locks, as does getContents. However,
> because getContents can operate on blocks, this requires many fewer
> locks.

What's to lock against?  I'm writing single-threaded code.  As for
getContents, "each time these lazy read functions are pulled on, they
have to check whether the handle has indeed been closed", which is not
entirely unlike locking.

While getContents / hGetContents is not defined directly in terms of
getChar / hGetChar, the implementation *does* do much the same things.
(Same blocking and buffering; for locks see previous paragraph.)  So
it was natural to wonder whether the difference was in *my* code and
if so, what I was doing wrong.




More information about the Haskell-Cafe mailing list