stdio line-streaming revisited

[kris]

Walter Bright wrote:
> kris wrote:
> 
>> On Win32, the difference is very much larger. As noted before, several 
>> times faster.
> 
> 
> I suspect that much of the slowness difference is from using C's fputs, 
> along with the need to append a 0 to use fputs.

Okay. Oh, seemingly dout.write() has some io-synch problems when used in 
this manner?


> std.stdio.readln will also automatically convert to char[] if the stream 
> is in wide character mode (as will all the phobos stdio functions). This 
> test is inlined and fast under Windows, but is a function call under 
> Linux which will hurt performance significantly.

Well, phobos is running as fast as perl under linux, so perhaps it 
doesn't seem to be much of an issue there? Under Win32, tango.io seems 
to leave everything else in the dust.

Seems kinda obvious why that is, when you look at what the "benchmark" 
is really testing? To me, it's likely spending most of its time 
constructing each line, so it's really not an IO test per se? Tango 
takes an alternate approach to such tasks, which would explains why it 
is so fast under Win32. What surprises us is that tango.io is almost 
sedate on linux by comparison. I can't explain that right now, but 
suspect it may have something to do with file locks, or something :)


>> If you mean something that you've written, that could presumeably be 
>> rectified by adding the isatty() test Walter had mentioned before. 
>> That has not been added to tango.io since (a) it would likely make 
>> programs behave differently depending on whether they were redirected 
>> or not. It's not yet clear whether that is an appropriate 
>> specialization, as default behaviour, and (b) there has been no ticket 
>> issued for it
>>
>> Again, please submit a ticket so we don't forget about that detail. 
>> We'd be interested to hear if folk think the "isatty() test" should be 
>> default behaviour, or would perhaps lead to corner-case issues instead
> 
> 
> Using isatty() to switch between line and block buffered I/O access is 
> routine when using C's stdio, and in fact is relied upon in DMC's 
> internal implementation of buffering. It's been this way for 25 years, 
> every C stdio implementation I've heard of uses it, and I've never heard 
> a complaint about it.

That's useful input ... thanks. It was noted that a program used both as 
a console process and a child process might behave differently, since 
flush would be automatic on the console yet not always so for the child 
(with redirected handles) ?