stdio performance in tango, stdlib, and perl
James Dennett
jdennett at acm.org
Sat Mar 24 19:25:38 PDT 2007
Andrei Alexandrescu (See Website For Email) wrote:
> James Dennett wrote:
>> As you appear to be saying that printf has to flush every
>> time it's used, I'd guess that it's unusable for performance
>> reasons alone.
>
> Numbers clearly tell the above is wrong.
Only if they apply to the above.
> Here's the thing: I write
> programs that write lines to files. If I use cout, they don't work. If I
> use fprintf, the do work, and 10 times faster. And that's that.
Except that your test wasn't of the right thing; you
probably didn't test code that guaranteed atomicity
of writes between different processes.
>> 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, or does its implementation make use
>> of platform-specific knowledge on which writes are atomic
>> at the OS level?
>
> The C standard library takes care of it without me having to do anything
> in particular.
I've never seen a C library that guarantees atomicity of
writes between processes on a Unix-like system. The
documentation of some systems does guarantee atomicity
of sufficiently small writes to certain types of file
descriptors, but I've not seen any Unix-like system
that guarantees atomicity for writes of unlimited sizes;
in some cases they can even be interrupted before the
full amount is written. I've certainly seen the result
of C's *printf *not* being synchronized between processes
on a wide variety of systems.
>> Within a process, this level of safety could be achieved
>> with only a little (usually redundant) synchronization.
>> Which is useful for debugging or simplistic logging,but
>> not for anything else I've seen.
>
> I do not concur.
With my description of my own experience? ;)
-- James
More information about the Digitalmars-d
mailing list