Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!umcp-cs!chris
From: chris@umcp-cs.UUCP (Chris Torek)
Newsgroups: net.unix
Subject: Re: why is fprintf(stderr,) slow?
Message-ID: <3026@umcp-cs.UUCP>
Date: Wed, 20-Aug-86 00:59:20 EDT
Article-I.D.: umcp-cs.3026
Posted: Wed Aug 20 00:59:20 1986
Date-Received: Thu, 21-Aug-86 01:26:08 EDT
References: <19300053@uiucdcsb>
Reply-To: chris@umcp-cs.UUCP (Chris Torek)
Organization: University of Maryland, Dept. of Computer Sci.
Lines: 18

In article <19300053@uiucdcsb> wsmith@uiucdcsb.CS.UIUC.EDU writes:
>I was doing some performance testing on a program and as part of it
>I was doing about 500 fprintf(stderr, "blah...\n");

>The program was taking 35 or 40 seconds of system time which was pretty
>high.  I then commented out the fprintf's and the program took 17 or 18
>system time seconds (it was doing a lot of disk accesses).

stderr is `traditionally' unbuffered.  That means that fprintf()s
to it write one character at a time.  This is indeed quite expensive.
The 4.3BSD fprintf---or more precisely, _doprnt---temporarily turns
on block buffering for some (but not all) operations.  I have, in
the past, added a `setbuf' or `setlinebuf' call to force buffering
on stderr.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@mimsy.umd.edu