Considerations of the time and timex commands

Edit online

Take several facts into account when you use either the time or the timex command.

These factors are:

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
```