GPROF(1)

๐Ÿ“ฆ
version 2.44 ยท 3 versions
, in debian trixie

okay bestie, pull up a chair ๐Ÿ’– this is the gprof page from the GNU manual, section 1 โ€” like, the "user commands" shelf. it's giving profiler energy and honestly it ate. let's get into it ๐Ÿซถ


โœจ NAME โœจ

gprof โ€” display call graph profile data ๐Ÿ‘‘


๐ŸŒธ SYNOPSIS ๐ŸŒธ

gprof [ -[abcDhilLrsTvwxyz] ] [ -[ABCeEfFJnNOpPqQRStZ][name] ]
 [ -I dirs ] [ -d[num] ] [ -k from/to ]
 [ -m min-count ] [ -R map_file ] [ -t table-length ]
 [ --[no-]annotated-source[=name] ]
 [ --[no-]exec-counts[=name] ]
 [ --[no-]flat-profile[=name] ] [ --[no-]graph[=name] ]
 [ --[no-]time=name] [ --all-lines ] [ --brief ]
 [ --debug[=level] ] [ --function-ordering ]
 [ --file-ordering map_file ] [ --directory-path=dirs ]
 [ --display-unused-functions ] [ --file-format=name ]
 [ --file-info ] [ --help ] [ --line ] [ --inline-file-names ]
 [ --min-count=n ] [ --no-static ] [ --print-path ]
 [ --separate-files ] [ --static-call-graph ] [ --sum ]
 [ --table-length=len ] [ --traditional ] [ --version ]
 [ --width=n ] [ --ignore-non-functions ]
 [ --demangle[=STYLE] ] [ --no-demangle ]
 [--external-symbol-table=name]
 [ image-file ] [ profile-file ... ]

๐Ÿ’œ DESCRIPTION ๐Ÿ’œ

gprof produces an execution profile of C, Pascal, or Fortran77 programs. the effect of called routines is incorporated in the profile of each caller. the profile data is taken from the call graph profile file (gmon.out is the default one, iconic behavior) which gets created by programs compiled with the -pg option of cc, pc, and f77. that -pg option also links in versions of the library routines that are compiled for profiling, slay โœจ

gprof reads the given object file โ€” default is a.out โ€” and establishes the relation between its symbol table and the call graph profile from gmon.out. if you hand it more than one profile file, the gprof output shows the sum of the profile information in the given profile files. math girlie behavior ๐Ÿ’…

heads up bestie: if you use gcc 2.95.x or 3.0 to compile your binaries, you may need to add the -fprofile-arcs to the compile command line in order for the call graphs to be properly stored in gmon.out. no cap, it's right there in the docs.

gprof calculates the amount of time spent in each routine. next, those times are propagated along the edges of the call graph. cycles are discovered, and calls into a cycle are made to share the time of the cycle. ๐Ÿ”„

several forms of output are available from the analysis. let's vibe check each one:

  • the flat profile shows how much time your program spent in each function, and how many times that function was called. if you simply want to know which functions burn most of the cycles, it is stated concisely here. ๐Ÿฅต
  • the call graph shows, for each function, which functions called it, which other functions it called, and how many times. there's also an estimate of how much time was spent in the subroutines of each function. this can suggest places where you might try to eliminate function calls that use a lot of time. ๐Ÿ•ธ๏ธ
  • the annotated source listing is a copy of the program's source code, labeled with the number of times each line of the program was executed. it's giving receipts ๐Ÿงพ

๐Ÿ’– OPTIONS ๐Ÿ’–

these options specify which of several output formats gprof should produce. pick your fighter ๐ŸŽ€

many of these options take an optional symspec to specify functions to be included or excluded. these options can be specified multiple times, with different symspecs, to include or exclude sets of symbols. stack 'em, bestie ๐Ÿซถ

specifying any of these options overrides the default (-p -q), which prints a flat profile and call graph analysis for all functions.
  • -A[symspec], --annotated-source[=symspec] โ€” the -A option causes gprof to print annotated source code. if symspec is specified, print output only for matching symbols. ๐Ÿ“
  • -b, --brief โ€” if the -b option is given, gprof doesn't print the verbose blurbs that try to explain the meaning of all of the fields in the tables. this is useful if you intend to print out the output, or are tired of seeing the blurbs. (lowkey same, we get it ๐Ÿ’€)
  • -B โ€” the -B option causes gprof to print the call graph analysis.
  • -C[symspec], --exec-counts[=symspec] โ€” the -C option causes gprof to print a tally of functions and the number of times each was called. if symspec is specified, print tally only for matching symbols.

if the profile data file contains basic-block count records, specifying the -l option, along with -C, will cause basic-block execution counts to be tallied and displayed. ๐Ÿงฎ

  • -i, --file-info โ€” the -i option causes gprof to display summary information about the profile data file(s) and then exit. the number of histogram, call graph, and basic-block count records is displayed. ๐Ÿ‘€
  • -I dirs, --directory-path=dirs โ€” the -I option specifies a list of search directories in which to find source files. environment variable GPROF_PATH can also be used to convey this information. used mostly for annotated source output. ๐Ÿ“‚
  • -J[symspec], --no-annotated-source[=symspec] โ€” the -J option causes gprof not to print annotated source code. if symspec is specified, gprof prints annotated source, but excludes matching symbols. ๐Ÿ™…
  • -L, --print-path โ€” normally, source filenames are printed with the path component suppressed. the -L option causes gprof to print the full pathname of source filenames, which is determined from symbolic debugging information in the image file and is relative to the directory in which the compiler was invoked. ๐Ÿ—บ๏ธ
  • -p[symspec], --flat-profile[=symspec] โ€” the -p option causes gprof to print a flat profile. if symspec is specified, print flat profile only for matching symbols.
  • -P[symspec], --no-flat-profile[=symspec] โ€” the -P option causes gprof to suppress printing a flat profile. if symspec is specified, gprof prints a flat profile, but excludes matching symbols.
  • -q[symspec], --graph[=symspec] โ€” the -q option causes gprof to print the call graph analysis. if symspec is specified, print call graph only for matching symbols and their children. ๐Ÿ‘‘
  • -Q[symspec], --no-graph[=symspec] โ€” the -Q option causes gprof to suppress printing the call graph. if symspec is specified, gprof prints a call graph, but excludes matching symbols.
  • -t, --table-length=num โ€” the -t option causes the num most active source lines in each source file to be listed when source annotation is enabled. the default is 10. ๐Ÿ”Ÿ
  • -y, --separate-files โ€” this option affects annotated source output only. normally, gprof prints annotated source files to standard-output. if this option is specified, annotated source for a file named path/filename is generated in the file filename-ann. if the underlying file system would truncate filename-ann so that it overwrites the original filename, gprof generates annotated source in the file filename.ann instead (if the original file name has an extension, that extension is replaced with .ann). ๐Ÿ—‚๏ธ
  • -Z[symspec], --no-exec-counts[=symspec] โ€” the -Z option causes gprof not to print a tally of functions and the number of times each was called. if symspec is specified, print tally, but exclude matching symbols.
  • -r, --function-ordering โ€” the --function-ordering option causes gprof to print a suggested function ordering for the program based on profiling data. this option suggests an ordering which may improve paging, tlb and cache behavior for the program on systems which support arbitrary ordering of functions in an executable. ๐Ÿง 

the exact details of how to force the linker to place functions in a particular order is system dependent and out of the scope of this manual. (iykyk, ask your linker bestie)

  • -R map_file, --file-ordering map_file โ€” the --file-ordering option causes gprof to print a suggested .o link line ordering for the program based on profiling data. this option suggests an ordering which may improve paging, tlb and cache behavior for the program on systems which do not support arbitrary ordering of functions in an executable.

use of the -a argument is highly recommended with this option. ๐Ÿ’ฏ

the map_file argument is a pathname to a file which provides function name to object file mappings. the format of the file is similar to the output of the program nm.

c-parse.o:00000000 T yyparse
c-parse.o:00000004 C yyerrflag
c-lang.o:00000000 T maybe_objc_method_name
c-lang.o:00000000 T print_lang_statistics
c-lang.o:00000000 T recognize_objc_keyword
c-decl.o:00000000 T print_lang_identifier
c-decl.o:00000000 T print_lang_type
...

to create a map_file with GNU nm, type a command like nm --extern-only --defined-only -v --print-file-name program-name. โœจ

  • -T, --traditional โ€” the -T option causes gprof to print its output in "traditional" BSD style. vintage but make it fashion ๐Ÿ•ฐ๏ธ
  • -w width, --width=width โ€” sets width of output lines to width. currently only used when printing the function index at the bottom of the call graph. ๐Ÿ“
  • -x, --all-lines โ€” this option affects annotated source output only. by default, only the lines at the beginning of a basic-block are annotated. if this option is specified, every line in a basic-block is annotated by repeating the annotation for the first line. this behavior is similar to tcov's -a. ๐ŸŒˆ
  • --demangle[=style], --no-demangle โ€” these options control whether C++ symbol names should be demangled when printing output. the default is to demangle symbols. the --no-demangle option may be used to turn off demangling. different compilers have different mangling styles. the optional demangling style argument can be used to choose an appropriate demangling style for your compiler. ๐Ÿฆ‹

๐Ÿ”ฅ Analysis Options ๐Ÿ”ฅ

  • -a, --no-static โ€” the -a option causes gprof to suppress the printing of statically declared (private) functions. (these are functions whose names are not listed as global, and which are not visible outside the file/function/block where they were defined.) time spent in these functions, calls to/from them, etc., will all be attributed to the function that was loaded directly before it in the executable file. this option affects both the flat profile and the call graph. ๐Ÿซฃ
  • -c, --static-call-graph โ€” okay so this one is lowkey a detective ๐Ÿ”. It takes the call graph and levels it up with a heuristic that examines the text space of the object file and sniffs out function calls in the binary machine code itself. Why tho? Because normal call graph records only get generated when functions are actually entered โ€” so this catches the children that could have been called, but never were. It also identifies calls to functions that weren't compiled with profiling enabled, but only if symbol table entries are present for them. Calls to dynamic library routines? Typically not found by this option, sorry bestie. Parents or children identified via this heuristic show up in the call graph with call counts of 0.
  • -D, --ignore-non-functions โ€” makes gprof ignore symbols that aren't known to be functions. On systems where it's supported (Solaris and HPUX, for example) this gives you more accurate profile data. Slay.
  • -k from/to โ€” lets you delete from the call graph any arcs from symbols matching symspec from to those matching symspec to. Cleanup era ๐Ÿงน.
  • -l, --line โ€” enables line-by-line profiling, which charges histogram hits to individual source code lines instead of to functions. Big caveat: this feature only works with programs compiled by older versions of the gcc compiler โ€” newer versions of gcc are designed to work with the gcov tool instead. If the program was compiled with basic-block counting enabled, this option will also identify how many times each line of code was executed. Line-by-line profiling can help isolate where in a large function a program is spending its time, but it also significantly increases the running time of gprof, and magnifies statistical inaccuracies. Tradeoffs, bestie ๐Ÿ’….
  • --inline-file-names โ€” prints the source file after each symbol in both the flat profile and the call graph. The full path to the file is printed if you use it with the -L option.
  • -m num, --min-count=num โ€” this one only affects execution count output. Symbols executed fewer than num times get suppressed. Bye ๐Ÿ‘‹.
  • -n symspec, --time=symspec โ€” in its call graph analysis, gprof will only propagate times for symbols matching symspec.
  • -N symspec, --no-time=symspec โ€” in its call graph analysis, gprof will not propagate times for symbols matching symspec. Same energy, opposite direction ๐Ÿ’œ.
  • -S filename, --external-symbol-table=filename โ€” makes gprof read an external symbol table file, like /proc/kallsyms, instead of reading the symbol table from the given object file (the default is a.out). This is so useful for profiling kernel modules ๐Ÿงโœจ.
  • -z, --display-unused-functions โ€” gprof will mention all functions in the flat profile, even the ones that were never called and had no time spent in them. This is useful in conjunction with the -c option for discovering which routines were never called. Ghost hunting fr fr ๐Ÿ‘ป.

๐ŸŒˆ Miscellaneous Options ๐ŸŒˆ

  • -d[num], --debug[=num] โ€” specifies debugging options. If num is not specified, all debugging is enabled. Go off.
  • -h, --help โ€” prints command line usage.
  • -O name, --file-format=name โ€” selects the format of the profile data files. The recognized formats are auto (the default), bsd, 4.4bsd, magic, and prof (not yet supported).
  • -s, --sum โ€” causes gprof to summarize the information in the profile data files it read in, and write out a profile data file called gmon.sum, which contains all the information from the profile data files that gprof read in. The file gmon.sum may be one of the specified input files; the effect of this is to merge the data in the other input files into gmon.sum. Eventually you can run gprof again without -s to analyze the cumulative data in the file gmon.sum. Data hoarding but make it โœจproductiveโœจ.
  • -v, --version โ€” prints the current version number, and then exits.

๐Ÿ’€ Deprecated Options ๐Ÿ’€

These options have been replaced with newer versions that use symspecs. Still here, still valid, but likeโ€ฆ the new ones are cuter.

  • -e function_name โ€” tells gprof to not print information about the function function_name (and its children...) in the call graph. The function will still be listed as a child of any functions that call it, but its index number will be shown as [not printed]. More than one -e option may be given; only one function_name may be indicated with each -e option.
  • -E function_name โ€” works like the -e option, but time spent in the function (and children who were not called from anywhere else) will not be used to compute the percentages-of-time for the call graph. More than one -E option may be given; only one function_name may be indicated with each -E option.
  • -f function_name โ€” causes gprof to limit the call graph to the function function_name and its children (and their children...). More than one -f option may be given; only one function_name may be indicated with each -f option.
  • -F function_name โ€” works like the -f option, but only time spent in the function and its children (and their children...) will be used to determine total-time and percentages-of-time for the call graph. More than one -F option may be given; only one function_name may be indicated with each -F option. The -F option overrides the -E option. Rude? A little. True? Yes.

๐Ÿ“ FILES ๐Ÿ“

  • a.out โ€” the namelist and text space.
  • gmon.out โ€” dynamic call graph and profile.
  • gmon.sum โ€” summarized dynamic call graph and profile.

๐Ÿ› BUGS ๐Ÿ›

Okay so here's the part where I have to be honest with you, bestie, because I love you and I want you to have correct expectations ๐Ÿ˜ญ.

The granularity of the sampling is shown, but it remains statistical at best. And there's an assumption baked in here: we assume that the time for each execution of a function can be expressed by the total time for the function divided by the number of times the function is called. Which means the time propagated along the call graph arcs to the function's parents is directly proportional to the number of times that arc is traversed. That's the model. That's the vibe.

Parents that are not themselves profiled will have the time of their profiled children propagated to them, but they will appear to be spontaneously invoked in the call graph listing, and will not have their time propagated further. Similarly, signal catchers, even though profiled, will appear to be spontaneous (although for more obscure reasons). Any profiled children of signal catchers should have their times propagated properly โ€” unless the signal catcher was invoked during the execution of the profiling routine, in which case, and I quote the energy here, all is lost ๐Ÿ’€.

And the big one, the one you cannot forget:

The profiled program must call exit(2) or return normally for the profiling information to be saved in the gmon.out file. No clean exit, no data. Periodt.

๐Ÿ‘€ SEE ALSO ๐Ÿ‘€

  • cc(1), prof(1), and the Info entry for gprof.
  • "An Execution Profiler for Modular Programs", by S. Graham, P. Kessler, M. McKusick; Software - Practice and Experience, Vol. 13, pp. 671-685, 1983.
  • "gprof: A Call Graph Execution Profiler", by S. Graham, P. Kessler, M. McKusick; Proceedings of the SIGPLAN '82 Symposium on Compiler Construction, SIGPLAN Notices, Vol. 17, No 6, pp. 120-126, June 1982.

Like, the receipts are right there if you want to go read the lore ๐Ÿ“šโœจ.


Copyright (c) 1988-2025 Free Software Foundation, Inc.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License".


and that's the whole page, bestie ๐Ÿซถ this gorgeous thing comes to you from binutils-2.44, dated 2025-03-28, and it's page GPROF(1). now go profile something and make it fast ๐Ÿ‘‘๐Ÿ’–

๐Ÿ“ฆ where this page comes from