1prof(1) User Commands prof(1)
2
6 prof - display profile data
7
9 prof [-ChsVz] [-a | c | n | t] [-o | x] [-g | l] [-m mdata]
10 [prog]
11
14 The prof command interprets a profile file produced by the monitor
15 function. The symbol table in the object file prog (a.out by default)
16 is read and correlated with a profile file (mon.out by default). For
17 each external text symbol the percentage of time spent executing
18 between the address of that symbol and the address of the next is
19 printed, together with the number of times that function was called and
20 the average number of milliseconds per call.
21
23 The mutually exclusive options -a, -c, -n, and -t determine the type of
24 sorting of the output lines:
25 -a Sort by increasing symbol address.
27 -c Sort by decreasing number of calls.
30 -n Sort lexically by symbol name.
33 -t Sort by decreasing percentage of total time (default).
36 The mutually exclusive options -o and -x specify the printing of the
40 address of each symbol monitored:
41 -o Print each symbol address (in octal) along with the symbol name.
43 -x Print each symbol address (in hexadecimal) along with the symbol
46 name.
47 The mutually exclusive options -g and -l control the type of symbols to
51 be reported. The -l option must be used with care; it applies the time
52 spent in a static function to the preceding (in memory) global func‐
53 tion, instead of giving the static function a separate entry in the
54 report. If all static functions are properly located, this feature can
55 be very useful. If not, the resulting report may be misleading.
56 Assume that A and B are global functions and only A calls static
59 function S. If S is located immediately after A in the source code
60 (that is, if S is properly located), then, with the -l option, the
61 amount of time spent in A can easily be determined, including the time
62 spent in S. If, however, both A and B call S, then, if the -l
63 option is used, the report will be misleading; the time spent during
64 B's call to S will be attributed to A, making it appear as if more
65 time had been spent in A than really had. In this case, function S
66 cannot be properly located.
67 -g List the time spent in static (non-global) functions separately.
69 The -g option function is the opposite of the -l function.
70 -l Suppress printing statically declared functions. If this option
73 is given, time spent executing in a static function is allocated
74 to the closest global function loaded before the static function
75 in the executable. This option is the default. It is the oppo‐
76 site of the -g function and should be used with care.
77 The following options may be used in any combination:
81 -C Demangle C++ symbol names before printing them out.
83 -h Suppress the heading normally printed on the report. This
86 is useful if the report is to be processed further.
87 -m mdata Use file mdata instead of mon.out as the input profile
90 file.
91 -s Print a summary of several of the monitoring parameters and
94 statistics on the standard error output.
95 -V Print prof version information on the standard error out‐
98 put.
99 -z Include all symbols in the profile range, even if associ‐
102 ated with zero number of calls and zero time.
103 A single function may be split into subfunctions for profiling by means
107 of the MARK macro. See prof(5).
108
110 PROFDIR The name of the file created by a profiled program is con‐
111 trolled by the environment variable PROFDIR. If PROFDIR is
112 not set, mon.out is produced in the directory current when
113 the program terminates. If PROFDIR=string, string/pid.prog‐
114 name is produced, where progname consists of argv[0] with
115 any path prefix removed, and pid is the process ID of the
116 program. If PROFDIR is set, but null, no profiling output
117 is produced.
118
121 mon.out default profile file
122 a.out default namelist (object) file
125
128 See attributes(5) for descriptions of the following attributes:
129 ┌─────────────────────────────┬─────────────────────────────┐
134 │ ATTRIBUTE TYPE │ ATTRIBUTE VALUE │
135 ├─────────────────────────────┼─────────────────────────────┤
136 │Availability │SUNWbtool │
137 └─────────────────────────────┴─────────────────────────────┘
138
140 gprof(1), exit(2), pcsample(2), profil(2), malloc(3C), malloc(3MALLOC),
141 monitor(3C), attributes(5), prof(5)
142
144 If the executable image has been stripped and does not have the .symtab
145 symbol table, gprof reads the global dynamic symbol tables .dynsym and
146 .SUNW_ldynsym, if present. The symbols in the dynamic symbol tables
147 are a subset of the symbols that are found in .symtab. The .dynsym sym‐
148 bol table contains the global symbols used by the runtime linker.
149 .SUNW_ldynsym augments the information in .dynsym with local function
150 symbols. In the case where .dynsym is found and .SUNW_ldynsym is not,
151 only the information for the global symbols is available. Without
152 local symbols, the behavior is as described for the -a option.
153 The times reported in successive identical runs may show variances
156 because of varying cache-hit ratios that result from sharing the cache
157 with other processes. Even if a program seems to be the only one using
158 the machine, hidden background or asynchronous processes may blur the
159 data. In rare cases, the clock ticks initiating recording of the pro‐
160 gram counter may beat with loops in a program, grossly distorting mea‐
161 surements. Call counts are always recorded precisely, however.
162 Only programs that call exit or return from main are guaranteed to
165 produce a profile file, unless a final call to monitor is explicitly
166 coded.
167 The times for static functions are attributed to the preceding external
170 text symbol if the -g option is not used. However, the call counts for
171 the preceding function are still correct; that is, the static function
172 call counts are not added to the call counts of the external function.
173 If more than one of the options -t, -c, -a, and -n is specified, the
176 last option specified is used and the user is warned.
177 LD_LIBRARY_PATH must not contain /usr/lib as a component when compiling
180 a program for profiling. If LD_LIBRARY_PATH contains /usr/lib, the
181 program will not be linked correctly with the profiling versions of the
182 system libraries in /usr/lib/libp. See gprof(1).
183 Functions such as mcount(), _mcount(), moncontrol(), _moncontrol(),
186 monitor(), and _monitor() may appear in the prof report. These func‐
187 tions are part of the profiling implementation and thus account for
188 some amount of the runtime overhead. Since these functions are not
189 present in an unprofiled application, time accumulated and call counts
190 for these functions may be ignored when evaluating the performance of
191 an application.
192 64-bit profiling
194 64-bit profiling may be used freely with dynamically linked executa‐
195 bles, and profiling information is collected for the shared objects if
196 the objects are compiled for profiling. Care must be applied to inter‐
197 pret the profile output, since it is possible for symbols from differ‐
198 ent shared objects to have the same name. If duplicate names are seen
199 in the profile output, it is better to use the -s (summary) option,
200 which prefixes a module id before each symbol that is duplicated. The
201 symbols can then be mapped to appropriate modules by looking at the
202 modules information in the summary.
203 If the -a option is used with a dynamically linked executable, the
206 sorting occurs on a per-shared-object basis. Since there is a high
207 likelihood of symbols from differed shared objects to have the same
208 value, this results in an output that is more understandable. A blank
209 line separates the symbols from different shared objects, if the -s
210 option is given.
211 32-bit profiling
213 32-bit profiling may be used with dynamically linked executables, but
214 care must be applied. In 32-bit profiling, shared objects cannot be
215 profiled with prof. Thus, when a profiled, dynamically linked program
216 is executed, only the main portion of the image is sampled. This means
217 that all time spent outside of the main object, that is, time spent in
218 a shared object, will not be included in the profile summary; the total
219 time reported for the program may be less than the total time used by
220 the program.
221 Because the time spent in a shared object cannot be accounted for, the
224 use of shared objects should be minimized whenever a program is pro‐
225 filed with prof. If desired, the program should be linked to the pro‐
226 filed version of a library (or to the standard archive version if no
227 profiling version is available), instead of the shared object to get
228 profile information on the functions of a library. Versions of profiled
229 libraries may be supplied with the system in the /usr/lib/libp direc‐
230 tory. Refer to compiler driver documentation on profiling.
231 Consider an extreme case. A profiled program dynamically linked with
234 the shared C library spends 100 units of time in some libc routine,
235 say, malloc(). Suppose malloc() is called only from routine B and B
236 consumes only 1 unit of time. Suppose further that routine A consumes
237 10 units of time, more than any other routine in the main (profiled)
238 portion of the image. In this case, prof will conclude that most of
239 the time is being spent in A and almost no time is being spent in B.
240 From this it will be almost impossible to tell that the greatest
241 improvement can be made by looking at routine B and not routine A.
242 The value of the profiler in this case is severely degraded; the solu‐
243 tion is to use archives as much as possible for profiling.
244SunOS 5.11 25 Aug 2009 prof(1)