Using the time Command to Measure CPU Use

The time command is a simple but useful tool for understanding the performance characteristics of a single program. time reports the elapsed time from beginning to end of the program, the real time. It also reports the amount of CPU time used by the program. The CPU time is divided into user and sys. The user value is the time used by the program itself and any library subroutines it calls. The sys value is the time used by system calls invoked by the program (directly or indirectly).

The sum of user + sys is total direct CPU cost of executing the program. This does not include the CPU costs of parts of the kernel that can be said to run on behalf of the program, but which do not actually run on its thread. For example, the cost of stealing page frames to replace the page frames taken from the free list when the program started is not reported as part of the program's CPU consumption.

The difference between the real time and the total CPU time, that is:

real - (user + sys)

is the sum of all of the factors that can delay the program, plus the program's own unattributed costs. In roughly the order of diminishing size, these factors may be:

• I/O required to bring in the program's text and data
• I/O required to acquire real memory for the program's use
• CPU time consumed by other programs
• CPU time consumed by the operating system

In the following example, the program used in the preceding section has been compiled with -O3 to make it quicker. There is very little difference between the real (wall-clock) time required to run the program and the sum of its user and system CPU times. The program is getting all the time it wants--probably at the expense of other programs in the system.

$ time looper
real    0m3.58s
user    0m3.16s
sys     0m0.04s

In the next example, we run the program at a lower priority by adding 10 to its nice value. It takes almost twice as long to run, but other programs are getting a chance to do their work too:

$ time nice -10 looper
real    0m6.54s
user    0m3.17s
sys     0m0.03s

Note that we placed the nice command within the time command, rather that the reverse. If we had entered

$ nice -10 time looper

we would have gotten a different time command (/usr/bin/time) with a lower-precision report, rather than the version of time we have been using, which is built into ksh. If the time command comes first, you will get the built-in version, unless you specify the fully qualified name of /usr/bin/time. If time is invoked from another command, you will get /usr/bin/time.

time and timex Cautions

There are several considerations that you should take into account when using time or its variant timex:

• The use of the /usr/bin/time and /usr/bin/timex commands is not recommended. When possible, use the time subcommand of the Korn or C shell. In AIX Version 3.2.5, /usr/bin/time incorrectly reports the CPU time used by a shell script containing a sequence of commands connected by pipes (the CPU time of all but the last command in the sequence is lost). This is because /usr/bin/time uses the system default shell. In AIX Version 3.2.5, the system default is the Bourne shell, which execs the commands in the sequence in such a way that only the CPU consumption of the last can be measured. In AIX Version 4, the system default shell is the Korn shell, which does not exhibit this phenomenon.
• The timex -s command uses sar to acquire additional statistics. Since sar is intrusive, timex -s is too. Especially for brief runs, the data reported by timex -s may not precisely reflect the behavior of a program in an unmonitored system.
• Because of the length of the system clock tick (10 milliseconds) and the rules used by the scheduler in attributing CPU time use to threads, the results of the time command are not completely deterministic. There is a certain amount of unavoidable variation between successive runs. This variation is in terms of clock ticks. Obviously, the shorter the run time of the program, the larger the variation will loom as a percentage of the reported result.
• Use of the time or timex command, whether from /usr/bin or via the built-in shell time function, to measure the user or system time of a sequence of commands connected by pipes, entered on the command line, is not recommended. One potential problem is that syntax oversights can cause time to measure only one of the commands, without any indication of a user error. The syntax is technically correct; it just doesn't produce the answer the user intended.