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