Performance Management Guide

Using the time Command to Measure CPU Use

Use the time command to understand the performance characteristics of a single program and its synchronous children. It reports the real time, that is the elapsed time from beginning to end of the program. 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 the 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.

On a uniprocessor, 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. On an SMP, an approximation would be as follows:

real * number_of_processors - (user + sys)

In approximately the order of diminishing size, the factors can 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 run more quickly. 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 less favorable priority by adding 10 to its nice value. It takes almost twice as long to run, but other programs are also getting a chance to do their work:

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

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

# nice -n 10 time looper

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

time and timex Cautions

Take several considerations into account when you use either the time or the timex command:

• 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.
• The timex -s command uses the sar command to acquire additional statistics. Because the sar command is intrusive, the timex -s command is also. Especially for brief runs, the data reported by the timex -s command 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. Because the time is sampled, there is a certain amount of unavoidable variation between successive runs. This variation is in terms of clock ticks. The shorter the run time of the program, the larger the variation as a percentage of the reported result (see Accessing the Processor Timer).
• Use of the time or timex command (whether from /usr/bin or through 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 the time command to measure only one of the commands, without any indication of a user error. The syntax is technically correct; it just does not produce the answer that the user intended.
• Although the time command syntax did not change, its output takes on a new meaning in an SMP environment:

  On an SMP the real, or elapsed time may be smaller than the user time of a process. The user time is now the sum of all the times spent by the threads or the process on all processors.

  If a process has four threads, running it on a uniprocessor (UP) system shows that the real time is greater than the user time:

  # time 4threadedprog
  real    0m11.70s
  user    0m11.09s
  sys     0m0.08s

  Running it on a 4-way SMP system could show that the real time is only about 1/4 of the user time. The following output shows that the multithreaded process distributed its workload on several processors and improved its real execution time. The throughput of the system was therefore increased.

  # time 4threadedprog
  real    0m3.40s
  user    0m9.81s
  sys     0m0.09s