Skip to content

Heaptrack v1.0.0 Release First stable release of the fast Linux heap memory profiler

I’m extremely happy to finally announce the first stable release of heaptrack, the FOSS heap memory profiler for C/C++ Linux applications. You can download the source tarball from the KDE mirrors:

Heaptrack is a fast heap memory profiler that runs on Linux. It allows you to track all heap memory allocations at run-time. Afterwards, the accompanying GUI tool can be used to find optimization opportunities in your code by analyzing the recorded profiling data. It allows you to:

  • Inspect peak heap memory consumption
  • Find memory leaks
  • Count overall number of memory allocations and find temporary allocations
  • Find small allocations with large overhead

You can use heaptrack pretty much wherever you are using Linux – it has been successfully used on 32bit and 64bit flavors of x86 and ARM platforms, both on embedded projects as well as desktop applications.

Using heaptrack

To use heaptrack to profile your native C/C++ application’s  heap memory consumption, please follow these steps:

  1. Install heaptrack: Following this release, the Linux distributions should start packaging heaptrack soon. Otherwise, see the accompanying the sources.
  2. Launch heaptrack: heaptrack <your application name> or run-time attach to a process via heaptrack -p <PID>
  3. Analyze the recorded data: heaptrack_gui heaptrack.<your-app>.<PID>.gz

Use the GUI to find hotspots in your code, then write a benchmark to get a reproducible setup to verify your performance improvements. Profile this benchmark with heaptrack again to get a baseline measurement, then improve the code and use heaptrack once more. Then you can compare this last data set against the baseline to verify that your code change does indeed result in a noticeable performance improvement.

The long road to the first release

Three years ago, I announced heaptrack’s initial proof-of-concept, which was very positively received by developers. Back then, it was already a usable tool to find issues related to the usage of heap memory in native Linux applications written in C/C++. Since then, heaptrack has already been used successfully by dozens of developers. I personally used it to optimize embedded automotive projects as well as the Qt library and various KDE libraries and applications. So, what took me so long to get a first release out?

I initially started this project out of the typical open source incentive: I used to rely on Valgrind’s massif for heap profiling, but it is very slow and the early data aggregation meant I could not add some useful features to my Massif-Visualizer, such as counting the total number of memory allocations. I decided to scratch my own itch and wrote heaptrack. Relatively quickly I had the proof-of-concept ready, which was “good enough” for many purposes and my motivation to ship a proper first release decreased.

Thankfully, KDAB decided to sponsor a couple of hours of my time to work on heaptrack in order to get a generally usable tool out to the masses. In this time, I mostly concentrated on the GUI for heaptrack. This GUI uses Qt and some KDE helper libraries to build a graphical data analysis of the data collected by heaptrack. The most notable features are:

The summary page of heaptrack, showing system information and top hotspots.
« 1 of 10 »

I hope you will find these data representations as useful as I do!

Getting all of these features properly implemented took quite some time. Tracking all memory allocations of an application easily generates millions of data points. A naive analysis of such an amount of data is going to be very resource intensive – it will consume lots of memory and time on your development machines. So for this first release, I already spent some time optimizing the analysis routines to decrease the resource demands.

The road ahead

I have already some ideas planned for the coming months to further improve heaptrack and its GUI. Most notably, I intend to introduce an “annotate source” feature. This will allow me to always use function-level aggregation in the data views. Additionally, I will work on the charts which are not yet as useful as they can be: I want to add filtering and zooming on the time axis, to inspect individual memory peaks. Especially to speed up the latter, I will also investigate different data formats to improve the analysis speed. Stay tuned!

If you want to get involved with heaptrack, there are multiple ways of doing so:

If you need help with using heaptrack, or with performance tooling in general, do note that we also offer a training course on debugging and profiling Qt applications. KDAB also offers on-site workshops and mentoring to aid you in optimizing your C++ application performance. I’ll gladly teach you how to use heaptrack effectively!

About KDAB

KDAB is a consulting company offering a wide variety of expert services in Qt, C++ and 3D/OpenGL and providing training courses in:

KDAB believes that it is critical for our business to contribute to the Qt framework and C++ thinking, to keep pushing these technologies forward to ensure they remain competitive.

created the Massif-Visualizer, heaptrack and hotspot tools now used widely to improve C++ and Qt applications performance. The co-maintainer of the KDevelop IDE, in 2015 he won the KDE Akademy Award for ongoing work in that. Milian has a Masters Degree in Physics and lives in Berlin. He is fluent in English and German.

3 thoughts on “Heaptrack v1.0.0 Release”

  1. Wow this is quite exciting indeed. I’ve used Valgrind memcheck before, but this looks quite promising. Will give it a go now with KStars, especially as we need to reduce memory footprint on limited resources devices like the Raspberry PI.

  2. The GUI tools look great!

    As for the low level part, it looks like you’ve been reinventing the wheel: gperf-tools and jemalloc have been doing this for many years. Why didn’t you build the visualization tools on top of the preexisting software?

    1. Milian Wolff

      Hey Erwan,

      the simple answer is that I was not aware of these solutions. See also my initial announcement at and search for “Reinventing the wheel”. Search also for the jemalloc comment and my response to that. Also note that heaptrack should work fine with an application that uses jemalloc internally. And contrary to jemalloc, you can also runtime-attach heaptrack, it’s agnostic to the malloc implementation.

      Do you see any advantages of using gperf-tools or jemalloc over heaptrack for memory profiling? I’d be very interested in learning more about those tools. If they are better in any aspect, It would be cool if someone wrote either a conversion tool for gperf-tools and jemalloc output, or separate parsers for heaptrack_gui.


Leave a Reply

Your email address will not be published. Required fields are marked *

By continuing to use the site, you agree to the use of cookies. More information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.