prof(1) prof(1)
NAME
prof - display profile data
SYNOPSIS
prof [-t | c | a | n] [-o | x] [-g | l] [-z] [-h] [-s] [-m mdata]
[-V] [prog]
DESCRIPTION
The prof command interprets a profile file produced by the monitor
function. The symbol table in the object file prog (a.out by default)
is read and correlated with a profile file, mon.out by default. For
each external text symbol the percentage of time spent executing
between the address of that symbol and the address of the next is
printed, together with the number of times that function was called
and the average number of milliseconds per call.
OPTIONS
The mutually exclusive options -t, -c, -a, and -n determine the type
of sorting of the output lines:
-t Sort by decreasing percentage of total time (default).
-c Sort by decreasing number of calls.
-a Sort by increasing symbol address.
-n Sort lexically by symbol name.
The mutually exclusive options -o and -x specify the printing of the
address of each symbol monitored:
-o Print each symbol address (in octal) along with the symbol name.
-x Print each symbol address (in hexadecimal) along with the symbol
name.
The mutually exclusive options -g and -l control the type of symbols
to be reported. The -l option must be used with care; it applies the
time spent in a static function to the preceding (in memory) global
function, instead of giving the static function a separate entry in
the report. If all static functions are properly located (see example
below), this feature can be very useful. If not, the resulting report
may be misleading.
Assume that A and B are global functions and only A calls static func-
tion S. If S is located immediately after A in the source code (that
is, if S is properly located), then, with the -l option, the amount of
time spent in A can easily be determined, including the time spent in
S. If, however, both A and B call S, then, if the -l option is used,
the report will be misleading; the time spent during B's call to S
will be attributed to A, making it appear as if more time had been
spent in A than really had. In this case, function S cannot be
Page 1 Reliant UNIX 5.44 Printed 11/98
prof(1) prof(1)
properly located.
-g Include static (non-global) functions.
-l Do not include static (non-global) functions (default).
The following options may be used in any combination:
-z Include all symbols in the profile range, even if associated with
zero number of calls and zero time.
-h Suppress the heading normally printed on the report. This is use-
ful if the report is to be processed further.
-s Print a summary of several of the monitoring parameters and
statistics on the standard error output.
-m mdata
Use file mdata instead of mon.out as the input profile file.
-V Print prof version information on the standard error output.
A program creates a profile file if it has been link edited with the
-p option of cc. This option to the cc command arranges for calls to
monitor at the beginning and end of execution. It is the call to moni-
tor at the end of execution that causes the system to write a profile
file. The number of calls to a function is tallied if the -p option
was used when the file containing the function was compiled.
The name of the file created by a profiled program is controlled by
the environmental variable PROFDIR. If PROFDIR is not set, mon.out is
produced in the directory current when the program terminates. If
PROFDIR=string, string/pid.progname is produced, where progname con-
sists of argv[0] with any path prefix removed, and pid is the process
ID of the program. If PROFDIR is set, but null, no profiling output
are produced.
A single function may be split into subfunctions for profiling by
means of the MARK macro.
NOTES
The times reported in successive identical runs may show variances
because of varying cache-hit ratios that result from sharing the cache
with other processes. Even if a program seems to be the only one using
the machine, hidden background or asynchronous processes may blur the
data. In rare cases, the clock ticks initiating recording of the pro-
gram counter may "beat" with loops in a program, grossly distorting
measurements. Call counts are always recorded precisely, however.
Only programs that call exit or return from main are guaranteed to
produce a profile file, unless a final call to the function monitor is
explicitly coded.
Page 2 Reliant UNIX 5.44 Printed 11/98
prof(1) prof(1)
The times for static functions are attributed to the preceding exter-
nal text symbol if the -g option is not used. However, the call counts
for the preceding function are still correct; that is, the static
function call counts are not added to the call counts of the external
function.
If more than one of the options -t, -c, -a, and -n is specified, the
last option specified is used and the user is warned.
Care must be taken when creating profiles for dynamically linked pro-
grams. Although this is fundamentally possible, the following restric-
tions must be borne in mind.
In order to be able to receive any output from prof, the library libc
must also be linked statically to the program, from which a profile is
to be created, when creating a dynamic link. This can be done with
"cc ... -Bstatic -lc -Bdynamic ..." without statically linking the
entire program in the process.
It is not normally possible to create profiles using prof for two
shared objects at present. Thus, when a profiled, dynamically linked
program is executed, only the "main" portion of the image is sampled.
This means that all time spent outside of the "main" object, that is,
time spent in a shared object, will not be included in the profile
summary; the total time reported for the program may be less than the
total time used by the program.
Because the time spent in a shared object cannot be accounted for, the
use of shared objects should be minimized whenever a program is pro-
filed with prof. If possible, the program should be linked statically
before being profiled.
Consider an extreme case. A profiled program dynamically linked with
the shared library (e.g. libsocket) spends 100 units of time in some
libsocket routine, say, bind. Suppose bind is called only from routine
B and B consumes only 1 unit of time. Suppose further that routine A
consumes 10 units of time, more than any other routine in the "main"
profiled portion of the image. In this case, prof will conclude that
most of the time is being spent in A and almost no time is being spent
in B. From this it will be almost impossible to tell that the greatest
improvement could be made by looking at routine B and not routine A.
The value of the profiler in this case is severely degraded. When you
want to profile a program, it is in your interest to use archives
instead of dynamically linked objects.
FILES
mon.out default profile file
a.out default name list (object) file
SEE ALSO
cc(1), exit(2), profil(2), monitor(3C).
Page 3 Reliant UNIX 5.44 Printed 11/98