Profile with gprof and code::blocks

[Dann Corbit]

I can profile with command line, but I would like to be able to do it from the IDE. Debugging GCC is so nice from code::blocks, it would be nice if I could stay there to do profiles.
But when I turn on the switch to do profiles, I get blank results. No errors or warnings, and I see profile data being written to disk, but the report is empty.

So, has anyone got a simple step by step for how to profile from code::blocks?

Yes, I really am getting lazy in my old age.

[Fabio Gobbato]

You have to first build the executable with the flags "Produce debugging symbols", "Profile code when executed" and optimizations disabled.
Then you have to run the executable and at the end you can go to Plugins->Code Profiler.
This steps should work.

[Dann Corbit]

Ick. If I have to disable optimizations, then the profiler cannot tell me what I want to know (which is when compiled for optimization, what are the bottlenecks in the code)

[Ras]

Ick. If I have to disable optimizations, then the profiler cannot tell me what I want to know (which is when compiled for optimization, what are the bottlenecks in the code)

The bottlenecks with optimisations will be the same as without, except if you have code parts that can be optimised away entirely. Profiling just tells you where most time is spent. Then you can optimise these hotspots and benchmark the execution time with compiler optimisation, but no profile generation.

[mvanthoor]

Ick. If I have to disable optimizations, then the profiler cannot tell me what I want to know (which is when compiled for optimization, what are the bottlenecks in the code)

The problem is that, when you leave optimizations enabled, the compiler inlines lots of functions. In the case of perft (which I've been profiling a few weeks ago), almost everything is inlined in perft itself, and so the profiler only tells you "perft takes a lot of time". If you leave out all optimizations, you'll see every function, down to functions within libraries. If they don't have debug symbols, the result is again "this function takes a lot of time", but you won't know where or why.

I've found, at least in case of Rust, that opt-level 2 is optimal.

In that case you don't see all the super-tiny functions in the (standard) library which you can't change anyway, but you will see the "big" functions in your program. It's then possible (in Intel VTUNE) to doubleclick a function, and the profiler will automatically highlight the most expensive part of that function.

With most of my functions, I'm now down to the level that copying values into the function's variable list and dropping them again and at the end of the function, are the most expensive parts... and this will be optimized out when the compiler inlines such a function.

So yes, you have to disable some optimizations (or almost everything will be inlined), but not all (or you will see way too much, even functions you can't even change).

[mar]

nobody sane measures performance with optimizations disabled. you'd get totally unreliable results.
nothing gets inlined, function prologue typically contains stack checks and fillers, nothing is cached in registers (everything spills), asserts are present in debug builds => typically debug builds run order of magnitude slower (YMMV)

what you want is to enable symbols/line numbers and profile a release build. you'll still get line numbers for inlined functions