Hello,

On 17-02-2009, Yaron Minsky <yminsky@gmail.com> wrote:
>
> Interestingly, this probably has nothing to do with the size of the buffer.
> input_char actually acquires and releases a lock for every single call,
> whether or not an underlying system call is required to fill the buffer.
> This has always struck me as an odd aspect of the in/out channel
> implementation, and means that IO is a lot more expensive in a threaded
> context than it should be.
>
>
> On Tue, Feb 17, 2009 at 5:07 AM, Sylvain Le Gall <sylvain@le-gall.net>wrote=
>>
>> You are using input_char and standard IO channel. This is a good choice
>> for non-threaded program. But in your case, I will use Unix.read with a
>> big buffer (32KB to 4MB) and change your program to use it. As
>> benchmarked by John Harrop, you are spending most of your time in
>> caml_enter|leave_blocking section. I think it comes from reading using
>> std IO channel which use 4k buffer. Using a bigger buffer will allow
>> less call to this two functions (but you won't win time at the end, I
>> think you will just reduce the difference between non-threaded and
>> threaded code).
>>

You are probably true concerning the fact that it has nothing to do with
size of the buffer. I am just mixing two kind of optimization. Anyway, I
think even if the size is not important, using Unix.read + file
descriptor should do the trick.

Thanks for your detailed explanation.

Regards
Sylvain Le Gall