prof(1) DG/UX 5.4.2 prof(1)
NAME
prof - display profile data
SYNOPSIS
prof [-tcan] [-ox] [-gl] [-z] [-h] [-s] [-m mdata] [prog]
DESCRIPTION
The prof command interprets a profile file produced by the
monitor(3C) 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 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 format (or base)
for printing 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 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.
Licensed material--property of copyright holder(s) 1
prof(1) DG/UX 5.4.2 prof(1)
-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 [see monitor(3C)],
even if associated 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 has been compiled with the -p
option of cc(1). This option to the cc command arranges for calls to
monitor(3C) at the beginning and end of execution. It is the call to
monitor at the end of execution that causes a profile file to be
written. The number of calls to a function is tallied if the -p
option was used to compile the file containing the function.
The name of the file created by a profiled program is controlled by
the environment variable PROFDIR. If PROFDIR does not exist, the
file mon.out is produced in the current directory. If PROFDIR =
string, the file string/pid.progname is produced, where progname
consists of argv[0] with any path prefix removed, and pid is the
program's process id. If PROFDIR is the null string, no profiling
output is produced.
A single function may be split into subfunctions for profiling by
means of the MARK macro [see prof(5)].
FILES
mon.out default profile file
a.out default namelist (object) file
SEE ALSO
cc(1), exit(2), profil(2), monitor(3C), prof(5).
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 program counter may ``beat'' with loops in a
program, grossly distorting measurements. Call counts are always
recorded precisely, however.
Licensed material--property of copyright holder(s) 2
prof(1) DG/UX 5.4.2 prof(1)
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 preceding
external 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.
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) 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 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.
Another profiling command, mxprof, works with Elf executables that
use shared objects and does not require special compilation or
linking. Mxprof is available in the separate product Mxdb, Data
General's Multi-Extensible Debugger.
Licensed material--property of copyright holder(s) 3