ka@june.cs.washington.edu (Kenneth Almquist) (05/20/89)
> On this system, as on several others, I've replaced /bin/true and /bin/false > with executables (which will be left as an exercise for the reader, since > posting them would be an intellectual insult to any True Unix Wizards ;-). > I've verified that the result is a measurable speedup in "while true" > loops, due to the elimination of the shell startup to run an empty script. I didn't believe this, so I tried executing the following loop: x=200 while ./true do x=`expr "$x" - 1` || break done When ./true was the empty file, the execution time was 8.2 real 0.4 user 3.4 sys Using a compiled C version of ./true decreased the real time to 6.4 real 0.5 user 4.2 sys These numbers are from ash; using /bin/sh instead produced a similar relative results: 28.0 real 2.0 user 15.4 sys 25.6 real 1.8 user 15.8 sys The system time makes sense: When ./true is a shell procedure rather than an executable, there is no need to load a new program into memory. (A new process is needed in either case, but if ./true is a shell procedure, only a fork is needed, not a fork and an exec.) But what about the real times? Why aren't they the same as the user plus the system times? One clue is that when ./true is a shell procedure, the name ./true is looked up twice. This is because an exec of ./true is done, and only when that fails does the shell realize that ./true is a shell procedure and open it. So I tried writing a little C program that opened and closed a file in the current directory 1000 times: 17.3 real 0.0 user 3.2 sys This is on an otherwise idle system running Ultrix 3.0, a 4.2 BSD derivative. I assume that it is blocking on disk I/O, but the machine has an 800K buffer cache, which ought to be large enough to hold every block that the open system call accesses. I know that on AT&T versions of UNIX, certain system calls use synchronous I/O to ensure that the file system is left in a relatively consistent state in the case of a system crash. But open? Is this a fanatical attempt to be sure that file access times aren't lost in a system crash, or what? Anyone figured this out? Kenneth Almquist