Reputation: 2611
Sorry, I can't create a minimal complete example as the problem only occurs for relatively large programs and I am not sure this is even a 'bug' per se as opposed to a misunderstanding of what callgrind profiling is supposed to accomplish.
I have a large program whose run time is split about 50 50 into 2 sequential parts. The first part is most file reading, and the second mostly computation.
The order of function calls that I would expect is the following:
main Part1_main
Part1_main Part1_main_subfunction_1
Part1_main Part1_main_subfunction_2
Part1_main Part1_main_subfunction_3
main Part2_main
Part2_main Part2_main_subfunction_1
Part2_main Part2_main_subfunction_2
..
..
When I run callgrind on the code (and then view the results in kcachegrind on osx), I have some results regarding the function calls that are approximately as you would expect except for one thing: There is no resolution of function calls within the second part: The profile output is qualitatively the same as
Part1_main 50 4
Part2_main 50 50
Part1_main_subfunction_1 20 4
Part1_main_subfunction_2 15 5
..
..
..
What is the interpretation that the second function has very high self time? It seems that the profiler thinks that it is not calling any other functions. I suppose it is possible, though unlikely, that everything in function 2 is inlined, so maybe there shouldn't be any further resolution. If this is true, this doesn't yield very interesting profiling results.
If you ever come across this type of thing, how do you force the profiler to show further resolution? Or, if my intuition is wrong, what else could be causing this behaviour?
As per instruction of the callgrind website, I am compiling with the -g flag, and optimisation turned on.
Upvotes: 0
Views: 377
Reputation: 451
As default kcachegrind hides functions with small weight, but you can customize it. See the answer here: Make callgrind show all function calls in the kcachegrind callgraph
Upvotes: 1