prof(1) User Commands prof(1)
prof - display profile data
prof [-ChsVz] [-a | c | n | t] [-o | x] [-g | l] [-m mdata]
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 mil-
liseconds per call.
The mutually exclusive options -a, -c, -n, and -t determine the type of sorting of the
-a Sort by increasing symbol address.
-c Sort by decreasing number of calls.
-n Sort lexically by symbol name.
-t Sort by decreasing percentage of total time (default).
The mutually exclusive options -o and -x specify the printing of the address of each sym-
-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, 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.
-g List the time spent in static (non-global) functions separately. The -g option func-
tion is the opposite of the -l function.
-l Suppress printing statically declared functions. If this option is given, time
spent executing in a static function is allocated to the closest global function
loaded before the static function in the executable. This option is the default.
It is the opposite of the -g function and should be used with care.
The following options may be used in any combination:
-C Demangle C++ symbol names before printing them out.
-h Suppress the heading normally printed on the report. This is useful if the
report is to be processed further.
-m mdata Use file mdata instead of mon.out as the input profile file.
-s Print a summary of several of the monitoring parameters and statistics on the
standard error output.
-V Print prof version information on the standard error output.
-z Include all symbols in the profile range, even if associated with zero number
of calls and zero time.
A program creates a profile file if it has been link edited with the -p option of cc(1B).
This option to the cc(1B) command arranges for calls to monitor at the beginning and end
of execution. It is the call to monitor 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.
A single function may be split into subfunctions for profiling by means of the MARK
macro. See prof(5).
PROFDIR The name of the file created by a profiled program is controlled by the envi-
ronment 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 with any
path prefix removed, and pid is the process ID of the program. If PROFDIR is
set, but null, no profiling output is produced.
mon.out default profile file
a.out default namelist (object) file
See attributes(5) for descriptions of the following attributes:
| ATTRIBUTE TYPE | ATTRIBUTE VALUE |
|Availability |SUNWbtool |
cc(1B), gprof(1), exit(2), pcsample(2), profil(2), malloc(3C), malloc(3MALLOC), moni-
tor(3C), attributes(5), prof(5)
If the executable image has been stripped and does not have the .symtab symbol table,
gprof reads the global dynamic symbol tables .dynsym and .SUNW_ldynsym, if present. The
symbols in the dynamic symbol tables are a subset of the symbols that are found in
.symtab. The .dynsym symbol table contains the global symbols used by the runtime linker.
.SUNW_ldynsym augments the information in .dynsym with local function symbols. In the case
where .dynsym is found and .SUNW_ldynsym is not, only the information for the global sym-
bols is available. Without local symbols, the behavior is as described for the -a option.
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 pro-
cesses 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 preceding external text symbol if the
-g option is not used. However, the call counts for the preceding function are still cor-
rect; that is, the static function call counts are not added to the call counts of the
If more than one of the options -t, -c, -a, and -n is specified, the last option speci-
fied is used and the user is warned.
LD_LIBRARY_PATH must not contain /usr/lib as a component when compiling a program for pro-
filing. If LD_LIBRARY_PATH contains /usr/lib, the program will not be linked correctly
with the profiling versions of the system libraries in /usr/lib/libp. See gprof(1).
Functions such as mcount(), _mcount(), moncontrol(), _moncontrol(), monitor(), and _moni-
tor() may appear in the prof report. These functions are part of the profiling implemen-
tation and thus account for some amount of the runtime overhead. Since these functions
are not present in an unprofiled application, time accumulated and call counts for these
functions may be ignored when evaluating the performance of an application.
64-bit profiling may be used freely with dynamically linked executables, and profiling
information is collected for the shared objects if the objects are compiled for profiling.
Care must be applied to interpret the profile output, since it is possible for symbols
from different shared objects to have the same name. If duplicate names are seen in the
profile output, it is better to use the -s (summary) option, which prefixes a module id
before each symbol that is duplicated. The symbols can then be mapped to appropriate mod-
ules by looking at the modules information in the summary.
If the -a option is used with a dynamically linked executable, the sorting occurs on a
per-shared-object basis. Since there is a high likelihood of symbols from differed shared
objects to have the same value, this results in an output that is more understandable. A
blank line separates the symbols from different shared objects, if the -s option is given.
32-bit profiling may be used with dynamically linked executables, but care must be
applied. In 32-bit profiling, 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 desired, the
program should be linked to the profiled version of a library (or to the standard archive
version if no profiling version is available), instead of the shared object to get profile
information on the functions of a library. Versions of profiled libraries may be supplied
with the system in the /usr/lib/libp directory. Refer to compiler driver documentation on
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 rou-
tine 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
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 ar-
chives as much as possible for profiling.
SunOS 5.11 8 Feb 2007 prof(1)