Skip to content

start:

Author: Stephan Bergmann. Last changed: $Date: 2005/01/12 16:00:37 $.

Callgrind How-To

Callgrind (also known under the names Calltree and KCachegrind) is a profiling tool that runs on Linux x86. It builds on the Valgrind framework and comes with a graphical frontend, kcachegrind.

This document concentrates on using callgrind on SuSE 9.2 to profile OpenOffice.org.

Installing Callgrind

On SuSE 9.2, just install the kdesdk3-profile package (which will also install the valgrind package as a dependency). To see call graphs in kcachegrind, you also need to install the graphviz package.

Doing so installs Callgrind version 0.9.8, Valgrind version 2.2.0, and KCachegrind version 0.4.5kde on your machine.

Useful documentation is locally installed at /usr/share/doc/packages/valgrind/ct_main.html. More documentation is available at KCachegrind, especially see the usage examples.

Profiling OpenOffice.org

No modification or instrumentation is necessary for profiling a sufficiently recent soffice.bin (I successfully tested this with OpenOffice.org 1.9.71). In the OpenOffice.org program directory, just execute

  callgrind ./soffice.bin

(When executing Java or some legacy dynamic libraries within soffice.bin, remember to extend LD_LIBRARY_PATH with the output of javaldx or with the OpenOffice.org program directory, respectively.)

When callgrind is finished, it writes a file callgrind.out.pid. Use

  kcachegrind callgrind.out.pid
to view it. I experienced the problem that the generated file is very small (around 500 byte) and does not contain the necessary information when profiling soffice.bin. In that case, it worked for me to execute

  callgrind --separate-threads=yes ./soffice.bin
instead, which writes out individual files callgrind.out.pid.thread together with an empty callgrind.out.pid. Opening that empty callgrind.out.pid in kcachegrind automatically reads in all the individual thread files.

Detailed information at the source/assembler instruction level can be gathered by specifying the additional callgrind options --dump-instr=yes and --trace-jump=yes.

Limitations

It worked fine for me to profile soffice.bin, just starting it up and immediately closing it again with Ctrl-Q, and to similarly profile soffice.bin -swriter. However, callgrind easily runs out of memory when gathering data for longer runs, or runs in which more dynamic libraries are loaded.

One solution to this problem might be to only gather data for parts of an soffice.bin run, using the --instr-atstart and --collect-atstart options to callgrind, and using the callgrind_control tool (see the documentation). One caveat when using callgrind_control can be that it reports that no callgrind processes are running. In that case, it can work to manually place a callgrind.cmd file in the current working directory. That is, instead of

  callgrind_control -i on

use

  echo +Instrumentation > callgrind.cmd

and instead of

  callgrind_control -d

use

  echo Dump > callgrind.cmd

Using instrumentation only during operations that should be profiled also speeds up the startup of soffice.bin, so it is recommended to use this whenever the startup itself is not of interest.

Rather than using callgrind_control or callgrind.cmd, it is also possible to turn on and off instrumentation using macros within the source code itself. This is especially useful if callgrind fails to work without manually turning on and off instrumentation, or if the same code shall be profiled several times. The macro to turn instrumentation on is CALLGRIND_START_INSTRUMENTATION(), and the macro to turn it off is CALLGRIND_STOP_INSTRUMENTATION(). Both are contained in callgrind.h, which unfortunately is not installed with callgrind, but can be downloaded separately. callgrind.h includes valgrind.h, which is installed in /usr/include/valgrind already.