prof -- display profile data


prof [-b format] [-tcan] [-ox] [-gl] [-h] [-m mdata ] [-s] [-z] [-V] [prog]

prof++ [-b format] [-tcan] [-ox] [-gl] [-h] [-m mdata ] [-s] [-z] [-V] [prog]


prof(CP) interprets a profile file produced by the monitor(S) function. The symbol table in the object file prog (named 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.

prof++(CP) pipes the output of prof through a filter that translates C++ mangled names to human-readable forms. This makes the output of prof more readable. C names are passed unchanged.

By default, prof scans prog to determine its file format and executes the appropriate binary. Use the option -b format to force prof to use a particular file format:

-b format
Do not scan prog. Use format as the file format of prog. format can be any one of elf, coff and ibcs2. ibcs2 is equivalent to coff. The case of format is not significant.

The mutually exclusive options -t, -c, -a, and -n determine the type of sorting of the output lines:

Sort by decreasing percentage of total time (default).

Sort by decreasing number of calls.

Sort by increasing symbol address.

Sort lexically by symbol name.

The mutually exclusive options -o and -x specify the printing of the address of each symbol monitored:

Print each symbol address in octal along with the symbol name.

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:

Include static (non-global) functions.

Do not include static (non-global) functions (default). This option is available only when prog is an ELF file.
The -l option, available when prog is an ELF file, 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.

If prog is a COFF file, prof attributes the times for static functions 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 in with the call counts of the external function).

The following options can be used in any combination:

Suppress the heading normally printed on the report. (This is useful if the report is to be processed further.)

-m mdata
Use the file mdata instead of mon.out as the input profile.

Print a summary of several of the monitoring parameters and statistics on standard error.

Include all symbols in the profile range (see monitor(S)), even if associated with zero number of calls and zero time.

Print prof version information on the standard error output. This option is available only when prog is an ELF file.

A program creates a profile if it has been loaded with the -p option of cc(CP). This option to cc arranges for calls to monitor(S) at the beginning and end of execution. It is the call to monitor at the end of execution that causes the profile to be written. 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 environment variable PROFDIR. If PROFDIR does not exist, mon.out is produced in the directory that is 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 program's process id. If PROFDIR is the null string, no profiling output is produced.

A single function can be split into subfunctions for profiling by means of the MARK macro (see prof(M)).


Only programs that call exit(S) or return from main( ) cause a profile file to be produced, unless a final call to monitor is explicitly coded.

The use of the -p option to cc(CP) to invoke profiling imposes a default limit of 600 functions that may have call counters established during program execution. If this limit is exceeded, other data are overwritten and the mon.out file is corrupted. For more counters you can call monitor(S) directly.

If prog is an ELF file, prog may have been built as a dynamically linked executable. Profiling may be used with dynamically linked executables, but care must be applied. Currently, dynamically linked libraries (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 dynamically linked library (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. See the -dn option of cc(CP).

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(S). Suppose that malloc( ) is called only from routine B, which 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.


The times reported in successive identical runs can show variances of 20% or more, because of varying cache-hit ratios due to sharing of the cache with other processes. Even if a program seems to be the only one using the machine, hidden background or asynchronous processes can 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.


default profile file

default namelist (object) file

See also

c++filt(CP), cc(CP), exit(S), monitor(S), prof(M), profil(S)

Standards conformance

prof(CP), is not part of any currently supported standard; it is an extension of AT&T System V that is maintained by The SCO Group.

© 2003 Caldera International, Inc. All rights reserved.
SCO OpenServer Release 5.0.7 -- 11 February 2003