Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!pyramid!chronon!eric
From: eric@chronon.UUCP (Eric Black)
Newsgroups: net.unix
Subject: Re: why is fprintf(stderr,) slow?
Message-ID: <338@chronon.chronon.UUCP>
Date: Fri, 29-Aug-86 13:49:51 EDT
Article-I.D.: chronon.338
Posted: Fri Aug 29 13:49:51 1986
Date-Received: Fri, 29-Aug-86 21:45:14 EDT
References: <633@hropus.UUCP> <1480@poseidon.UUCP> <7074@utzoo.UUCP>
Reply-To: eric@chronon.UUCP (Eric Black)
Organization: (none)
Lines: 19

In article <7074@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes:
>> > Standard error is unbuffered, eg, one char at a time, so it makes one
>> > write system call per character, hence its slowness.
>> Surely you mean "per call".
>It *ought* to be "per call".  On many systems, in *fact* it is "per character".

Of course, the reason that it was made per character is to make sure that
the error output in fact gets out, and is not lost in stdio buffering somewhere
when an errant program suddenly gives up the ghost.  On BSD systems,
at least, you can change this with the setlinebuf(3S) call, to make
stderr use buffering.  Nowadays, with buffered stdio output less likely
to get lost (?), perhaps it is too bad that the default is still
to make a system call per character, rather than per call, but...

On non-BSD systems you're stuck, as far as I know.

-- 
Eric Black   "Garbage In, Gospel Out"
UUCP:        {sun,pyramid,hplabs,amdcad}!chronon!eric