This is a easy one. I need to profile Linux C++ programs:

Must requirements:

  • free for non-commercial use
  • work with gcc (g++) compiled programs
  • work with x86-64 programs.
  • profile programs compiled with optimizations enable (-O3). (* see footnote)
  • display real (demangled) symbol names, even with optimization enable. (* see footnote)

Useful features:

  • easy to use for basic profiling (detect the hot code)
  • line granularity (which lines within a function are hot)
  • assembly instructions granularity

Would be nice features:

  • GUI (even 3'rd party)
  • easy to install

Future requirements (I don’t need it right now, but I will need it in the near future):

  • profile multithreaded programs
  • work with clang (would be nice)

As an example, on Windows, the Visual Studio Profiler is very good.

I gave gprof a try on Linux, but couldn’t make it work with optimization enable, even with -g -pg.

(*) Debug and profiling information can be required to exist (e.g. -p -g -pg).


I profile my programs with the valgrind plugin/tool callgrind.

For me, this works under x86_64 with optimizations as -O3 when adding debugging symbols with -g. Valgrind is licensed under the GPL.

The output can be visualized with kcachegrind or the Eclipse Linux Tools

The callgrind manual states, that it can do assembly analysis and deal with forks if they correctly annotated in source.

It is easy to use:

valgrind --tool=callgrind ./path/to/executable

It runs the program slower than normal and creates a file callgrind.out.$pid where $pid is the pid of the invocation (it is the number displayed in every line of callgrind's output ==$pid==).

It can then be visualized in kcachegrind with

kcachegrind callgrind.out.$pid
  • Pity callgrind is too slow... What about gprof/sprof? Mar 17 '16 at 14:02

You should at least know about the random pausing technique. It doesn't meet all of your requirements, but it is more effective than any automated profiler at finding what you call "hot" code, what I call "opportunities for speedup".

The reason it is more effective is this.

Imagine an ideal profiler. Suppose it took random-time samples of the program's state (including stack and memory, for all threads). Suppose it had artificial intelligence and automatic programming capability, so it could understand the program as well as the person who wrote it. Suppose it examined each sample and determined the full reason for that moment in time being spent, and was looking for a way to avoid spending that time, by possibly changing something. If it saw such an opportunity for speedup, and saw it on fraction X of the samples, it could recommend that if you do that change, you could save up to fraction X of the time.

Wouldn't that be a great profiler? It could find all kinds of things, not just functions spending a lot of time that you can't do anything about.

It is worth asking - how many samples would it need to take? The usual assumption is - the more the better - better precision. WRONG! You're trying to find the problem, not measure it. If a speedup opportunity takes fraction X of time, it will take fraction X of 10,000 samples, and it will take fraction X of 10 samples (roughly). So if it's big enough to be worth fixing, it doesn't take many samples. In fact, it only has to see a problem twice to know it is significant. On average, it needs 2/X samples, so if X is 0.3, it needs 6.67 samples. (The statistical justification is here.)

Well, if you don't mind using your own head, and taking a few samples manually, like with jstack or a debugger, you already own that ideal profiler. Plenty of programmers know this, and use it to make their code blazingly fast.

  • This is not an answer to the question for a software recommendation
    – user416
    Apr 24 '15 at 14:34
  • 2
    @JanDoggen: It is recommending the use of a debugger, which comes with any IDE or compiler distribution. Isn't that software? I know it's very hard to question the premise that to do profiling you need a profiler tool, but failing to question that premise results in large speedup factors not being found. IMHO, the reason programmers like profilers is they have confirmation bias. In other words, they like to hear that there is no way to speed up their code - it is essentially optimal, even though that may well not be true. Apr 24 '15 at 16:12

Allinea MAP matches everything on your list - it also handles your "future requirements" as it does threads. There is nothing else like it - it has a very low overhead - usually <5% whereas callgrind is well over 100%.

It is commercial - but in the interest of complete answers belongs here.

  • 1
    I upvoted your answer, but in the interests of completeness feel compelled to mention that the cheapest license costs GBP 635 (US $950) Mar 11 '15 at 8:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.