What is gprof?
(written by Steve Wolfman)
Gprof is a profiling program which collects and arranges
statistics on your programs.Basically, it looks into each of your
functions and inserts code at the head and tail of each one to collect
timing information (actually, I don't believe it checks each time the
function is run, but rather collects statistically significant
samples). Then, when you run your program normally (that means with
any std and file i/o you would normally have), it creates
"gmon.out"... raw data which the gprof program turns into profiling
statistics (which tell you all sorts of neat stuff).
How to Use GProf in 5 Easy Steps.
-
Get your program working!! gprof is not a
debugger. Use it once you have a working program to optimize that
program.
-
Compile and link with the -pg option. If you use an Owen Astrachan
patented makefile this simply means changing the CFLAGS variable.
-
Run your program normally; that is, pretend you didn't do anything
to it and do what you would normally do (checking difficult, slow, or
fast cases, of course).
-
Type gprof exec > out where
exec is replaced by your executable's name and
out by some meaningful name for the profiling
information. For instance, if your executable were "foo" on the third
run compiled with the -O2 option then you might type:
gprof foo > run3.withO2.stats
-
Look over the output and learn what it means. Hint, go to the
second table. The first is pretty useless. To get there,
search for "granularity" twice from the top of the file (in emacs, use
C-s; in less or more use /).
Some advice
Read the stuff at the beginning. It does a good job of explaining the
output you get from gprof.
Ignore internal_mcount!!!!! You can't get rid of
it. Even with the -E option. It's all gprof's fault. Write hate-mail
to gnu (but don't tell them I told you to).
Leave out the -g option and maybe even include the -O (or -O2 or -O3)
option in your compilation. Otherwise, you get biased timing
information. Try man gprof and man gcc.
Optimize the big time-suckers and the high frequency called functions
first! That's where you make your big gains. Oh, and don't bother with
stuff that contributes 2 microseconds to a 2 minute program! Useless
optimizations waste much more time than they save!
If you have any significant human or even file i/o then remember that
results may vary widely from run to run due to system and
user response time. Factor that in (and run more than once... check
out the -s option in man gprof). In fact, factor it in even if you
don't have any i/o.
Check out the -D option in man gprof. I think it might be neat if you
were really interested in optimization.
If gprof left wierd looking nasty function names in your
results, use "c++filt". Just type c++filt
__ugly.:^)identifier, replacing
__ugly.:^)identifier with the offending expression. For instance:
c++filt __vc__11SymbolTablei
will return:
SymbolTable::operator[](int)
From garbage to method! If c++filt isn't recognized, it may not be in
your path. Try /usr/local/bin/c++filt on cs. On acpub
use ~ola/bin/c++filt .
If you just type c++filt with no argument, you may enter a
series of mangled names. End with ^D or ^C.
Finally, if you discover anything in your gprof forays that I should
add to this, please tell me and I will.