stdio performance in tango, stdlib, and perl

[Sean Kelly]

Walter Bright wrote:
> 
> D's implementation of writef does the same thing. D's writef also wraps 
> the whole thing in a try-finally, making it exception safe.
> 
> Iostreams'
>     cout << a << b;
> results in the equivalent of:
>     (cout->out(a))->out(b);
> The trouble is, there's no place to hang the lock acquire/release, nor 
> the try-finally. It's a fundamental design problem.

The stream could acquire a lock and pass it to a proxy object which 
closes the lock on destruction.  This would work fine in C++ where the 
lifetime of such objects is deterministic, but the design is incredibly 
awkward.

>> It's also really hard to implement such a
>> guarantee on most platforms without using some kind of
>> process-shared mutex, file lock, or similar.  Does printf
>> really incur that kind of overhead every time something is
>> written to a stream,
> 
> It does exactly one lock acquire/release for each printf, not for each 
> character written.

This is still far too granular for most uses.  About the only time I 
actually use output without explicit synchronization are for throw-away 
debug output.

>> or does its implementation make use
>> of platform-specific knowledge on which writes are atomic
>> at the OS level?
>>
>> Within a process, this level of safety could be achieved
>> with only a little (usually redundant) synchronization.
> 
> The problem is such synchronization would be invented and added on by 
> the user, making it impossible to combine disparate libraries that write 
> to stderr, for example, in a multithreading environment.

This is a valid point, but how often is it actually used in practice? 
Libraries generally do not perform error output of their own, and 
applications typically have a coherent approach for output.  In my time 
as a programmer, I can't think of a single instance where default 
synchronization to an output device actually mattered.  I can certainly 
appreciate this for its predictable behavior, but I don't know how often 
that predictability would actually matter to me.

>> Which is useful for debugging or simplistic logging,but
>> not for anything else I've seen.

Exactly.


Sean