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.