Profiling allows you to learn where your program spent its time and which functions called which other functions while it was executing. This information can show you which pieces of your program are slower than you expected, and might be candidates for rewriting to make your program execute faster. It can also tell you which functions are being called more or less often than you expected. This may help you spot bugs that had otherwise been unnoticed.
Since the profiler uses information collected during the actual execution of your program, it can be used on programs that are too large or too complex to analyze by reading the source. However, how your program is run will affect the information that shows up in the profile data. If you don’t use some feature of your program while it is being profiled, no profile information will be generated for that feature.
Profiling has several steps:
gprof to analyze the profile data.
See gprof Command Summary.
The next three chapters explain these steps in greater detail.
Several forms of output are available from the analysis.
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. See The Flat Profile.
The call graph shows, for each function, which functions called it, which other functions it called, and how many times. There is 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. See The Call Graph.
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. See The Annotated Source Listing.
To better understand how profiling works, you may wish to read a description of its implementation. See Implementation of Profiling.