Thread: Can gprof go into each self-defined function?

Originally Posted by lehe

Hi,
I am trying to use gnu profiler gprof to find out which operations cost most of the time, for example, I heard that exp can be very time expensive. However all I can get from gprof analysis is only the count of each self-defined function, but not the count for each operations inside each self-defined function. I guess gprof probably could do this, and was wondering how to get this infomation?
Thanks in advance!

Compile your code with full debug information (-g -pg) and use the -l (the letter ell, in case your font doesn't make it obvious) argument when you invoke gprof to get line-by-line profile information.

Obviously, you are not able to "look inside" functions from the C library itself, such as exp(), unless you have a profile build of the C library. But you should be able to see the total time spent in that function.

Originally Posted by lehe

Thanks brewbuck!
I was wondering if -g is needed, since I saw on page 77 in "An Introduction to GCC", there is no -g specified.
I guess if adding -g, gprof will count in the operations in the source code as it is written; If not,, the optimized operations will be counted?
Seems like with -g it is easier to find out which operation costs most. But If I eventually need to use the optimized executable, would it be better to not include -g in compilation?

You only need "-g" if you want line-by-line profiling. Otherwise gprof does not have enough information to determine the specific line numbers.

To profile an optimized executable, use both "-g -pg" and "-O". In some cases you may want to use "-fno-inline" to get more accurate results on a per-function basis, but these results don't translate to a fully optimized scenario since inlining should improve performance.

Note that "-g" does not impact optimization. Debugging information and optimization are fully compatible. It just makes debugging harder because code can be re-ordered and variables optimized into nothingness.

EDIT: Also, optimization will most likely cause some confusion about the exact line numbers, again, because code gets moved around. It's better than nothing, though.