KDAB Hotspot: a Qt GUI for reading Linux perf.data files

The gap between perf record and a readable profile

perf record produces a perf.data file. perf report reads it back as text. For a function with a deep call chain, that text output makes it hard to see which caller is responsible for the samples, and there is no way to ask a question like "what was running between 12:00 and 12:05" without writing the filter yourself.

Hotspot is KDAB's answer to that. It is a standalone GUI, built with Qt, whose first stated goal is to provide a UI like KCachegrind around Linux perf. The README describes it as an R&D effort, and says the intention is to support other performance data formats later under the same umbrella. That framing matters: the tool is not a replacement for perf, it is a viewer for what perf already wrote.

The audience is therefore narrow and specific. You need to be on Linux, you need perf to be able to record on the machine, and you need to be comfortable reading a call graph. If you profile with Instruments, VTune or a sampling profiler that emits its own format, Hotspot has nothing to open.

What the GUI actually renders and how the data flows

The data flow is short. perf writes perf.data, Hotspot opens it, and the Qt views are populated from the parsed samples. The README lists the main views: a summary page, a FlameGraph page, an off-CPU analysis view, caller-callee, bottom-up and top-down pages, and a disassembly view. Inlined functions are drawn with a darker border than non-inlined ones, so the graph distinguishes frames that the compiler merged.

The timeline is the part that differs most from terminal output. According to the README, it allows filtering the results by time, process or thread, and the data views update accordingly. The screenshots show filtering applied to a FlameGraph and zooming into the timeline to inspect individual samples. That is a real workflow advantage: you can isolate a slow phase of a run without re-recording.

Hotspot can also drive perf itself. The record page can launch a new application under perf or attach to already running processes. The README points at its own caveats section about recording without super user rights, which is worth reading before you assume attach will work on a locked-down machine.

Two smaller features are worth knowing because they show where the project spends effort. There is a tracepoints view, and there is support for Rust v0 symbol mangling, which matters if you profile a Rust binary and otherwise get unreadable names. The command line accepts --sysroot to locate libraries and --kallsyms to resolve kernel symbols, which is the hook for profiling a target whose libraries are not in the host's default paths.

Installing Hotspot and opening a first profile

The README is explicit that Hotspot is not packaged on all Linux distributions, and that in those cases the AppImage is the intended route. Gentoo users can get ebuilds from the KDAB overlay. Everyone else should check the packaging status badge or use the AppImage from the current release or the continuous build.

The AppImage is downloaded from the release assets. The README says to untar it first in the case of the latest release, then make it executable and run it. It also notes that system libraries and preferences are not altered, and that removing Hotspot means deleting the downloaded file.

Before any of that, you need data. The README's first instruction is to record with perf using dwarf callgraph mode, because that is what produces backtraces the GUI can walk.

perf record --call-graph dwarf <your application>

With a perf.data in the working directory, launching Hotspot opens it automatically, in the same spirit as perf report. You can also pass a path explicitly.

hotspot /path/to/perf.data

If you want to convert a recording into the smaller perfdata format, or set a GUI setting from the shell, the options are exposed on the command line and listed by --help. The README shows --sysroot and --kallsyms among them.

Broken backtraces, debuginfod and the missing features list

The README keeps a Known Issues section, and the first entry is broken backtraces. That is the failure mode that hurts most, because a flame graph built on a shallow or wrong stack is confidently wrong. The README's own remedy is to record with --call-graph dwarf, which is why that flag appears in the getting-started instructions rather than buried in a troubleshooting page.

The second entry is debuginfod. Symbol resolution for system libraries depends on debug information being available, and the README treats that as a known issue rather than a solved problem. In practice this is the boundary of the tool: Hotspot can only show you a function name if the debug info for that binary can be found.

There is also a Missing Features entry, and a note about recording with perf without super user rights. Hotspot does not work around the kernel's perf_event_paranoid restrictions; if the system refuses to let perf record or attach, the GUI inherits that refusal. The Export File Format is listed as a known issue too, which is a signal to verify round-tripping before you build a workflow on the converted format rather than on perf.data itself.

One more boundary is worth stating plainly: this is a desktop GUI. There is no headless mode described in the README for producing a report inside CI. If your profiling happens on a build machine and the report needs to be attached to a pull request, Hotspot is the wrong tool for that step.

How Hotspot differs from KCachegrind and perf report

KCachegrind is the reference point the README itself names, and the difference is the input format. KCachegrind reads callgrind output produced by Valgrind, which means the program runs under an instrumenting simulator: slow, but with exact call counts and no sampling error. Hotspot reads perf.data from hardware or software sampling, which runs at close to native speed and gives you a statistical picture.

That trade-off has consequences the GUI cannot hide. A flame graph from sampling shows where time was observed, not where it was spent in a deterministic sense. Short functions may never appear. Conversely, you can profile a production binary for a few seconds without a large slowdown, which callgrind does not allow.

Against perf report itself, the difference is presentation and interaction rather than data. perf report gives you sorted tables in a terminal; Hotspot gives you the same samples as a graph you can click through, plus the timeline filter that the terminal does not offer. If you are already comfortable in perf report and rarely need to slice by time, the GUI adds little. If you spend your time explaining a profile to someone else, the visual form is the point.

Licence and what upgrading involves

The repository ships LICENSE.GPL.txt at its top level, and the desktop integration files use the com.kdab.Hotspot identifier. The README's License section is the authoritative place to read the terms; the GPL file in the tree is the concrete evidence of which licence applies. If you plan to redistribute Hotspot inside a product image, read that file and the README section together rather than assuming the AppImage's convenience implies permissive terms. This is not legal advice.

On upgrades, the release history shows two kinds of artefact. There are tagged releases, with v1.6.0 dated 2026-02-27 and v1.5.1 described as a bug fix release dated 2024-05-28, and there is a continuous build dated 2026-09-09. The README tells users to prefer the latest build for the most recent version, and to fall back to the latest stable release and report a bug if it does not work. That is an unusual instruction, and it means the continuous AppImage is treated as the primary download for people who want current code.

The cost of upgrading is low because the AppImage is self-contained: you download a new file and delete the old one, and the README states your system libraries and preferences are not altered. Distribution packages move at their own pace, so a distro install and an AppImage can sit at quite different versions on the same machine. Pick one and stay with it to avoid confusion about which build produced a given view.

Editorial conclusion

Adopt Hotspot if you already record with perf and want to read the results graphically, especially if you need to filter a profile by time or thread. Do not adopt it if your profiling data does not come from Linux perf, or if you need a headless report on a build server. Before relying on it, check that your distro packages it or that the AppImage runs on your system, and record with --call-graph dwarf so the backtraces are usable.

Frequently asked questions

Official sources

1. Issues
2. KDAB/hotspot on GitHub
3. README
4. Releases