Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!mcnc!rti!dg-rtp!hunt From: hunt@dg-rtp.dg.com (Greg Hunt) Newsgroups: comp.unix.questions Subject: Re: Question on printf() Message-ID: <1990Jun16.211847.1391@dg-rtp.dg.com> Date: 16 Jun 90 21:18:47 GMT References: <24674.266e3b81@kuhub.cc.ukans.edu> <1990Jun8.030206.4532@virtech.uucp> <1990Jun15.042610.18292@dasys1.uucp> <13132@smoke.BRL.MIL> Sender: usenet@dg-rtp.dg.com (Usenet Administration) Reply-To: hunt@dg-rtp.dg.com Organization: Data General Corp., Research Triangle Park, NC Lines: 61 In article <13132@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes: |> In article <1990Jun15.042610.18292@dasys1.uucp> jpr@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@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.