Ketil Malde writes: > Couldn't readFile et al. provide the standard interface, > but use hGetBuf tricks (e.g. from your 'wc' entry) behind > the curtains?
No amount of hGetBuf'ing will speed the program up if the problem is the algorithm. I/O comes _sequentially_, and every program that doesn't process the input sequentially will require some form of buffering. Lazy I/O provides a great general-purpose buffering mechanism, but it simply can't be as fast of as efficient as hand-written code. IMHO, a good I/O API forces you to write a stateful callback function (that's how I implemented it in BlockIO), so _if_ you want to buffer something, you can use your state for that. But the I/O driver doesn't buffer, what has been read and processed is gone. Then the I/O part will _always_ be as fast as possible, and the design encourages you to process the data sequentially without looking forward/backward too much. It simply means writing a Char -> StateT st IO () -- stream processor or String -> StateT st IO () -- line oriented function to handle a _part_ of the input every time, rather than a String -> IO () function that handles the entire input at once. Peter _______________________________________________ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe