stdio performance in tango, stdlib, and perl
Sean Kelly
sean at f4.ca
Sat Mar 24 21:06:07 PDT 2007
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
More information about the Digitalmars-d
mailing list