prof(1) MAXION/OS 1.2v9 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.
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 print-
ing 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 function 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
1
prof(1) MAXION/OS 1.2v9 prof(1)
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 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 asso-
ciated with zero number of calls and zero time.
-h Suppress the heading normally printed on the report.
(This is useful 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 monitor at the end of execu-
tion 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 con-
trolled 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 consists of
argv[0] with any path prefix removed, and pid is the process
ID of the program. If PROFDIR is set, but null, no profil-
ing output are produced.
A single function may be split into subfunctions for profil-
ing by means of the MARK macro [see prof(5)].
Files
mon.out default profile file
a.out default namelist (object) file
2
prof(1) MAXION/OS 1.2v9 prof(1)
REFERENCES
cc(1), exit(2), monitor(3C)
NOTICES
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 pro-
gram 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
monitor is explicitly coded.
The times for static functions are attributed to the preced-
ing external text symbol if the -g option is not used. How-
ever, 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 speci-
fied, the last option specified is used and the user is
warned.
Profiling may be used with dynamically linked executables,
but care must be applied. Currently, shared objects cannot
be profiled with prof. 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 profiled 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 C library spends 100 units of time in
some libc routine, say, malloc. Suppose malloc 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) por-
tion 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
3
prof(1) MAXION/OS 1.2v9 prof(1)
tell that the greatest improvement can be made by looking at
routine B and not routine A. The value of the profiler in
this case is severely degraded; the solution is to use
archives as much as possible for profiling.
Modified, August 1996
4