KCachegrind: a KDE front end for Cachegrind and Callgrind profiles

A visualiser, not a profiler

KCachegrind and QCachegrind are a KDE and Qt GUI to visualize profiling data. The naming reflects the split: the K version is the KDE application, the Q version is the Qt-only one, and both come from the same codebase.

They are mainly used as a visualization frontend for data measured by the Cachegrind and Callgrind tools from the Valgrind package, and the README is explicit that converters are available for other measurement tools. The repository layout has a converters/ directory alongside the main source, so the import path for other profilers exists in the tree rather than being a separate project.

The distinction between measuring and visualising is the first thing to internalise, because the README makes a point of it. Any work in improving the performance of a program should be started by measuring the performance characteristics of the optimised binary using representative input data, and the README calls that process profiling, adding that any other way of performance optimisation usually just wastes developer time. What the application does is take the resulting measurements and make them legible.

The audience is a systems or performance engineer working on C or C++ code, or a student learning to read a profile. The homepage is the KDE invent page, the project is not archived, and the last push was on 2026-10-10.

One thing the README does not say is which licence applies, and the repository listing shows a LICENSES/ directory alongside a kcachegrind.spec.in packaging file, so the terms are in the tree rather than stated on this page.

What the views actually show you

The feature list describes what you get once a profile is loaded.

There is direct support for profiles generated by Cachegrind and Callgrind, and support for arbitrary event types and derived event types. That second point matters more than it first appears. A callgrind file can carry instruction counts, branch mispredictions and cache miss rates as separate event types, and a profile with only instruction counts tells you where the program spends its time but not where it stalls on memory. Being able to switch the event being visualised, and to define derived ones, is what separates a viewer from a text dump.

The function list is sorted, with grouping according to the ELF object, source file and symbol namespace, such as C++ classes. Grouping by namespace is what lets you collapse a thousand template instantiations into one line when you are trying to find where the time is going at the level of your own code rather than in the standard library.

There is correct handling of recursive cycles, similar to GProf, which matters because a naive inclusive-cost calculation will double count or loop on a cycle and produce numbers that are simply wrong.

The visualisation views for a selected function are the part you will live in. There is a treemap in the caller and callee direction, a call graph around the function, and source and assembly annotation. The treemap answers where the cost is concentrated at a glance, the call graph answers how control arrives there, and the source and assembly annotation answers which line and which instruction is responsible.

The README notes that the application has detailed What's this help for each GUI part, with quick start pages on kcachegrind.sf.net, so the in-app help is a real documentation surface rather than a stub.

Building the Qt version with qmake

The two applications build in two different ways, and the README documents them separately.

QCachegrind is the Qt-only one. Its requirements are Qt5.x, with x >=2, and earlier versions not tested, plus any platform supported by Qt, which the README lists as Linux, Windows, Mac OS X and others. The compilation from the base directory is:

	qmake; make

And if you would rather not build in the source directories, the README gives the out-of-source variant:

	mkdir build; cd build; qmake ../qcg.pro; make

The qmake project file is qcg.pro at the repository root, which matches the ../qcg.pro path in that second command.

The build also produces a command line tool, cgview, which is worth knowing about even if you never open the GUI. The cgview/ directory at the top of the repository is that tool, and it gives you a way to inspect a profile file over SSH or in a container where a desktop session is not available.

Installing the Qt build by hand means putting the qcachegrind binary on your PATH, and for better desktop integration copying the .desktop file and the icons into their standard locations:

	sudo install -m 755 qcachegrind/qcachegrind /usr/local/bin
	sudo install -m 644 qcachegrind/qcachegrind.desktop \
		/usr/local/share/applications/
	sudo install -m 644 kcachegrind/hi32-app-kcachegrind.png \
		/usr/local/share/icons/hicolor/32x32/apps/kcachegrind.png
	sudo install -m 644 kcachegrind/hi48-app-kcachegrind.png \
		/usr/local/share/icons/hicolor/48x48/apps/kcachegrind.png

Those four commands are the whole manual installation, and the icon sizes match the two hicolor directories a desktop environment looks in.

Building the KDE version with CMake

KCachegrind proper has different requirements. You need KF 5.12 or higher, the Frameworks development packages with libraries and headers, and CMake. The commands from the base directory are:

	cmake .; make; make install

Or, to keep the build out of the source tree:

	mkdir build; cd build; cmake ..; make; make install

One subtlety is worth flagging because it is easy to trip over. The KCachegrind build also compiles the command line tool cgview and qcachegrind, the Qt-only version of KCachegrind, but these are not installed. If you want qcachegrind as well, the README sends you back to the QCachegrind instructions above, which is why the manual install block above is worth keeping to hand.

The repository carries the files that a modern KDE project is expected to have. There is a CMakeLists.txt and a CMakePresets.json at the root, plus a .kde-ci.yml for KDE's own continuous integration and a .gitlab-ci.yml, a kcachegrind.spec.in for RPM packaging, a .flatpak-manifest.json with a matching license file, and a snapcraft.yaml, so the application is packaged for Flatpak and Snap as well as for system distributions.

The source is split into libcore/, libviews/, kcachegrind/, qcachegrind/ and cgview/, which reflects the separation between the data model, the visualisation layer and the two front ends.

Packaging, translations and what is not documented

A few details in the repository listing are worth reading for what they imply about the project's shape.

There is a po/ directory and a separate poqm/ directory. The first is the usual gettext translation tree, and the second is for the Qt translation files, which is a signal that the two applications are translated separately because they are separate binaries with separate string sets. The Messages.sh script is the helper that regenerates them.

There is an AUTHORS file, a ChangeLog, a NEWS file, a TODO, a KnownBugs file and a Mainpage.dox, which is the documentation convention of a long-lived desktop application. The Mainpage.dox is what Doxygen renders, and the README_DEVELOPER file is the developer onboarding document, a division of labour that suggests the project has a stable core and a steady contributor base rather than a burst of new work.

What the README does not cover is worth stating plainly. There is no mention of a supported profile format beyond Cachegrind and Callgrind and the converters, no version compatibility matrix for the Valgrind releases, and no statement about which Qt or KF versions are tested beyond the Qt5.x and KF 5.12 minimums. The homepage is the KDE invent page, and the quick start material lives on kcachegrind.sf.net rather than in the repository.

For an evaluation, the practical question is whether the profile you can produce is one of the formats the converters handle, and the answer is in the converters/ directory rather than in the documentation.

Editorial conclusion

Adopt KCachegrind if you profile C or C++ code with Valgrind's Cachegrind or Callgrind and want to see where the time and the cache misses go rather than reading a flat profile file. Do not adopt it for profiling outside the Valgrind ecosystem without checking the converters directory, and do not expect it to profile on its own, since it visualises data that something else has to produce. Verify first that your platform can build it, since the Qt path needs Qt5.x and the KDE path needs KF 5.12 or higher, and that the profile file format your measurement tool produces is one the converters can read.

Frequently asked questions

Official sources

1. Issues
2. KDE/kcachegrind on GitHub
3. Project website
4. README