Question on printf()

[Greg Hunt]

In article <13132 at smoke.BRL.MIL>, gwyn at smoke.BRL.MIL (Doug Gwyn) writes:
|> In article <1990Jun15.042610.18292 at dasys1.uucp> jpr at dasys1.UUCP
(Jean-Pierre Radley) writes:
|> >>3. add a setbuf(stdout,(char *) 0) at the begining of your program.  This 
|> >>turns off all output buffering and can have a detrimental effect on the
|> >>overall performance of your software.  
|> >Why is that?
|> 
|> Because it turns off buffering on the stdout stream!
|> I suppose your real question is, what is buffering good for.
|> By buffering several sequential putchar()s (or equivalent)
|> in a data area belonging to the C library stdio implementation
|> (linked into your application), and performing a system call
|> to write out the entire buffer just once when the buffer fills
|> up (or, in some circumstances, whenever a new-line character
|> is seen), instead of a system call per character as must be
|> done when buffering is disabled, obviously the number of
|> system calls to transfer the same amount of data is
|> drastically reduced. Since there is considerable overhead
|> involved in making a system call, minimimizing the number of
|> system calls made leads to better application performance.
|> 

While the cost of doing the extra system calls is something to be
considered, I believe that the more significant cost associated with
doing multiple I/O's is the actual time it takes the device to do the
I/O.  Devices are very slow compared to operations purely done in
memory (like buffering).

Most devices that I know of, including disks, tapes, and terminals,
all have different throughput rates depending on the size of the I/O
being done.  Some disks that I have worked with, for example, can
handle a single block I/O request in about .020 seconds.  If you try
a two block I/O, you'll find it is also handled in about the same
amount of time.  This continues until you hit some design point where
you'll see a sharp increase in the time it takes, say between 20 and
21 block I/O's.  Then the pattern continues for another 20 blocks.

So, if you need to write 20 blocks, you could write them one block
at a time, but this would take 20 * .020 seconds, or .400 seconds.  On
the other hand, you could write all 20 blocks at once, which would only
take you about .020 seconds.  That difference is why buffering, where
applicable, makes a great deal of sense.  It can be a huge performance
win.  The cost of the system calls itself is a contributing factor, but
the speed of the device is a greater factor, I think.

I believe that terminals exhibit this same pattern, but of course the
I/O times are probably quite different from the speed of a disk drive.

The pattern is highly dependent on the device's and controller's
characteristics, and the way the operating system interacts with the
device.  The pattern is not necessarily linear or even regular.  There
are frequently bizzare spikes that cannot easily be explained.

Of course, your mileage may vary.

--
Greg Hunt                        Internet: hunt at dg-rtp.dg.com
Data Management Development      UUCP:     {world}!mcnc!rti!dg-rtp!hunt
Data General Corporation
Research Triangle Park, NC       These opinions are mine, not DG's.