Functions 'disappears' while profiling.

[überfuzz]

I have a program which I try to clock, or profile. When I compile with -O flags some functions disappears from the out put from gprof. Is there an explanation to this..?

Thanks!

[ZuK]

The compiler might have inlined them.
Kurt

[grumpy]

The compiler might have inlined them.

In fact, one common effect of using -O style of options is to increase likelihood of certain types of functions being inlined.

Another explanation is that the "function" is actually a macro. Macros work by modifying code before the compiler sees it, so will never appear explicitly in the executable, let alone be recognised by a debugger or profiler.

[iMalc]

Or, if you have functions which produce identical assembly, the linker may optimise the resuling assembly to only have one copy of the function.

[Salem]

I have a program which I try to clock, or profile. When I compile with -O flags some functions disappears from the out put from gprof. Is there an explanation to this..?

Thanks!

Of course, this would be a lot easier if you posted an actual short example showing us exactly what you're seeing.

[ledow]

-O applies optimisations, as stated above.

If you want to profile, profile your WORST case, i.e. your debug build with no optimisation. Then you know where the bottlenecks are and optimisation by the compiler can only make things better. If you have a build with enough debug information in it to profile, then you're not really having the best code you can anyway - just the profiling code itself can be a source of slowdown, and the debug symbols etc. that need to be included will impact any caching etc. that you might benefit from anyway.

So DELIBERATELY make your profiled code as bad as possible (i.e. no optimisation, debug symbols, etc.), re-code as necessary to improve it, and you know that your WORST case will never be that bad in your actual production code.