The callgraph in kcachegrind

Note: I did not write kcachegrind, so the below might be completely wrong!

Note too that the call graph from op2calltree.py, or from op2kcg without a gprof file, will have all call-counts set to one. To get correct call counts one needs to use valgrind with --tool=callgrind or operf and gprof as described here.

For a particular piece of code, profiled with callgrind, the following call graph was produced.

The red box around the __sorts_MOD_sift_in shows that it is the active function for this graph. The graph applies only when that function is active, so if __sorts_MOD_smooth_extract also calls __sorts_MOD_smooth_heapify, but such a call never results in a call to __sorts_MOD_sift_in, then, with __sorts_MOD_sift_in active, no line between __sorts_MOD_smooth_extract and __sorts_MOD_smooth_heapify would be shown. So different connectivity can appear depending which function is active, and the active function need not be at the bottom of the graph.

Furthermore, there are several rules for suppressing functions and connection lines. By default children (callees) are shown to infinite depth, parents (callers) to a depth of just two, and nodes and lines are shown only if they have at least 5% of the activity of the active node. If one changes the callers depth to 5 and the node cutoff to 1% (by right-clicking on the pane) then the graph changes as below.

Not only is the relationship between __sorts_MOD_smoothsort and __sorts_MOD_smooth_extract now clearer, but reducing the node cutoff to 1% causes the line between __sorts_MOD_smooth_heapify and __sorts_MOD_interheap_sift to appear.

Changing focus

In the image below the focus has changed to __sorts_MOD_interheap_sift (by double-clicking on it). This removes the link between __sorts_MOD_smooth_heapify and __sorts_MOD_sift_in, for that path is never used if __sorts_MOD_interheap_sift is active.

Perhaps the advice for minimum surprises should be to set the focus as high up the call graph as possible. In the image below it is set on (Fortran's equivalent) of main, and suddenly one sees that a random number routine is also present. However, the larger cost of the function with focus means that the link from __sorts_MOD_smooth_heapify and __sorts_MOD_interheap_sift is now too insignificant to be shown. The large number of functions listed in the flat profile with trivial costs are also not shown.