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__11SymbolTableiwill 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.