time

The time commaned is excellent at giving a breakdown of how the execution of the program was split between system mode and user mode operations.

time dbaccess database eric.sql
real 0m7.57
user 0m0.10
sys 0m0.03

real	the time the program took to execute
user	the time the program was executing code for the application that did not require any system resources. This is equivalent to the sum of the tms_utime and tms_cutime fields returned by the times(2) function for the process in which utility is executed.
sys	the time the required to run all the code that used or requested system resources. This is equivalent to the sum of the tms_stime and tms_cstime fields returned by the times() function for the process in which utility is executed.

The use of /usr/bin/time and /usr/bin/timex are not recommended, whenever possible the shell built-in should be used. In AIX 3.2.5, for example /usr/bin/time incorrectly reports the CPU time used by a shell script that contains a series of command connected by pipes. This is due the fact that /usr/bin/time uses the default shell (ie /bin/sh), which execs the commands in such a way that only the CPU consumption is reported. AIX 4.x does not have this problem.

timex -s command uses sar to acquire additional statistics and because sar is intrusive so is timex -s This is exaggerated on programs with a short run time.

Because of the length of the system clock tick 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 varition between successive runs, this variation is in terms of clock ticks.

Use of the time or timex, whether the executable or built-in to measure a series of commands connected by pipes on the command line is not recommended. One potential problem is syntax oversight which might cause time to measure only one of the commands. The syntax is correct but the command does not produce the results as expected.