# 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.