Take the 2-minute tour ×

I have a C++ application I'm in the process of optimizing. What tool can I use to pinpoint my slow code?

share|improve this question

closed as off-topic by Andrew Medico, lpapp, Reto Koradi, EdChum, Raul Rene Jul 22 at 7:38



This should not be closed. Does nobody ever reopen questions? –  mike nelson Sep 10 '13 at 2:13
@mikenelson: It's being called "not constructive", which seems strange. I don't know about closing, but as far as deleting is concerned, there are hundreds of people, besides me, who see value here. –  Mike Dunlavey Sep 13 '13 at 20:07

24 Answers 24

up vote 765 down vote accepted





Caveat: programmers tend to be skeptical of this technique unless they've used it themselves. They will say that profilers give you this information, but that is only true if they sample the entire call stack. Call graphs don't give you the same information, because 1) they don't summarize at the instruction level, and 2) they give confusing summaries in the presence of recursion. They will also say it only works on toy programs, when actually it works on any program, and it seems to work better on bigger programs, because they tend to have more problems to find.








0.1    1     1             0.1          0.1            0.25974026
0.1    0.9   0.81          0.081        0.181          0.47012987
0.1    0.8   0.64          0.064        0.245          0.636363636
0.1    0.7   0.49          0.049        0.294          0.763636364
0.1    0.6   0.36          0.036        0.33           0.857142857
0.1    0.5   0.25          0.025        0.355          0.922077922
0.1    0.4   0.16          0.016        0.371          0.963636364
0.1    0.3   0.09          0.009        0.38           0.987012987
0.1    0.2   0.04          0.004        0.384          0.997402597
0.1    0.1   0.01          0.001        0.385          1

                  P(o=2/2) 0.385                




0.001  1    1              0.001        0.001          0.072727273
0.001  0.9  0.81           0.00081      0.00181        0.131636364
0.001  0.8  0.64           0.00064      0.00245        0.178181818
0.001  0.7  0.49           0.00049      0.00294        0.213818182
0.001  0.6  0.36           0.00036      0.0033         0.24
0.001  0.5  0.25           0.00025      0.00355        0.258181818
0.001  0.4  0.16           0.00016      0.00371        0.269818182
0.001  0.3  0.09           0.00009      0.0038         0.276363636
0.001  0.2  0.04           0.00004      0.00384        0.279272727
0.991  0.1  0.01           0.00991      0.01375        1

                  P(o=2/2) 0.01375                





share|improve this answer
Thank you SO much for this idea. I just used it and I was able to identify and ameliorate some serious bottlenecks light years faster than any other method I've tried in the past. I sped up execution by 60 times. I shudder at the thought of all the timing debugging code I was considering adding. –  ErikE Jan 20 '10 at 0:48

You can use valgrind with the following options

valgrind --tool=callgrind ./(Your binary)


share|improve this answer
That's fantastic! thanks for the tip –  Matt Nov 13 '10 at 9:03
Thanks. This really is a great application. I'm going to show it off to everyone in the office. –  agscala Oct 3 '11 at 20:52


Be sure to add -pg to compilation before profiling:

cc -o myprog myprog.c utils.c -g -pg


Related question here.


share|improve this answer




alt text

share|improve this answer

oprofile is good because it makes it much easier than gprof to profile multiple programs at once. You also can run it on your release build (if it has symbols), instead of having to build a special profiling build.

If you don't care about taking a massive performance hit (50x), valgrind (cachegrind) is good.

share|improve this answer
+1, oprofile is great for looking at an entire system, and for profiling code in kernel space –  orip Jan 20 '09 at 18:29
Oprofile also seems to work better than gprof for functions coded in assembly than many other tools. –  Lara Dougan Nov 11 '09 at 7:21
oprofile is always described as a kernel profiler or system profiler. I've never used it as such. I set oprofile to filter on the executable I'm currently working on and ignore the kernel and the rest of the system. It's honestly the best way to find performance problems. As a bonus OProfile and measure statistics other than raw CPU usage. My personal favorite is L2_cache misses, perfect for finding cache thrashing in threaded code. –  deft_code Mar 2 '10 at 0:50
oprofile needs excessive setup, is unreliable and I wasted 2 hours just to try it out. When I could get results, the results were good though. –  jturcotte Jul 27 '12 at 13:27
If you're just profiling one executable, run it with the "operf" command. That makes it really easy, and no setup required. –  peastman Dec 18 '13 at 20:41

You can use callgrind. Together with KCacheGrind, it gives a pretty nice profiler. Besides that, Intel VTune is free for educational use on Linux. It is probably the best profiler out there. If you have an AMD CPU, use AMD Codeanalyst (succeeded by AMD’s CodeXL), which is also available for Linux; this one is only decent, but free.

share|improve this answer
I've had success with AMD Codeanalyst even on Intel chipsets. Very nice tool for a freebie :) –  Mike Jun 18 '09 at 21:14
Well, but it sometimes gives very weird results, and it's not too stable... if it works, it's good, but I didn't get it working too often. –  Anteru Jun 20 '09 at 12:43





share|improve this answer

Oprofile is a decent free option, but I've had better luck using Zoom. It's a commercial (free eval) profiler for Linux that has a sweeet GUI for seeing hotspots in your source code.

share|improve this answer
** I'm a profiler-skeptic, but I have to admit, Zoom seems to be on the right track. I would have them butterfly lines of code, rather than routines, and get rid of the "Self" column. They should let you pick particular stack traces to look at. And, they take about 1000 times more samples than necessary. But they are on what I think is the right track (after all these years of gprof-ism). –  Mike Dunlavey Dec 9 '09 at 15:54
+1 for Zoom - version 2.0 came out recently: rotateright.com –  Paul R Jun 24 '11 at 8:23

This is a response to Nazgob's gprof answer.

I've been using gprof the last couple of days and have already found 3 significant limitations, one of which I've not seen documented anywhere else (yet):



  3. It says here that "... the number-of-calls figures are derived by counting, not sampling. They are completely accurate...". Yet I find my call graph giving me 5345859132+784984078 as call stats to my most called function, where the first number is supposed to be direct calls, and the second recursive calls (which are all from itself). Since this implied I had a bug, I put in long (64bit) counters into the code and did the same run again. My counts : 5345859132 direct, and 78094395406 self-recursive calls. There's a lot of digits there, so I'll point out the recursive calls I measure are 78bn, versus 784m from gprof : a factor of 100 different. Both runs were single threaded and unoptimised code, one compiled -g and the other -pg.

This was GNU gprof (GNU Binutils for Debian) running under 64-bit Debian Lenny, if that helps anyone.

share|improve this answer

What about Valgrind?

Pretty sure you can use Cachegrind or some similar plugin to do profiling.

share|improve this answer
callgrind (valgrind --tool=callgrind)! And that's absolutely awesome: you get the percentage of CPU used by literally any function called during your runtime. I found tons of loops in my threads thanks to this! –  Gui13 Feb 27 '12 at 14:30

In addition to Intel Vtune / AMD CodeAnalyst, perfmon2 is a OSS alternative, that requires a patched kernel to open up the CPU performance counter, and that would give you various performance figure that you can gather. perfmon2 is still implementation specific, i.e. L2 cache misses are called different things on intel P3 compared to AMD64, and they're beginning work on perfmon3, which should unify the API.

But generally, gprof would work well enough for you to detect slow code.

share|improve this answer

You may have a look to gprof. The gnu profiler.

Another interesting tool may be IBM rational quantify but it's not free

share|improve this answer

You can use Sun Studio's collect/analyzer. Using collect you can also profile memory usage, threads, MPI, etc. You also get a nice timeline view of your program.

If you use these tools in Solaris you can also get hardware performance counter information like in vtune or oprofile.

You can get this (and other very useful tools from Sun) at: Oracle Solaris Studio 12.3

share|improve this answer
Yes, it is interesting and powerful. It has a functionality almost as rich as professional commercial profiler –  osgx Dec 18 '10 at 4:44

I've had very good luck with Rational Quantify (expensive but very good) and oprofile. Be aware when using oprofile that its a statistical profiler, not a full-on tracing profiler like Quantify. oprofile uses a kernel module to poke into the call stack of every running process on every interval so certain behaviors may not be caught. Using multiple profilers is good, especially since different profilers tend to give you different data all of which is useful.

As for using gprof, its ok. I would get one of the graphical front-ends, since the data can be rather difficult to get through just on the command line. I would avoid valgrind, until you require memory checking.

share|improve this answer

google-perftools is the only reasonable alternative to gprof I've found. It's quite usable, familiar, and I believe it's time sampling, so that IO bottlenecks are revealed, in addition to the usual CPU bottle necks that gprof discovers. It's also significantly less invasive.

share|improve this answer
I should add that it occasionally has problems on 64bit. –  Matt Joiner Jan 26 '12 at 4:13
could you mention what these problems are? –  static_rtti Jun 19 '12 at 12:06
@static_rtti: The issues are as documented: code.google.com/p/gperftools/source/browse/trunk/README#207 –  Matt Joiner Jun 19 '12 at 15:39

Answer to run valgrind --tool=callgrind is not quite complete without some options. We usually do not want to profile 10 minutes of slow startup time under valgrind and want to profile our program when it is doing some task.

So this is what I recommend. Run program first:



callgrind_control -i on


callgrind_control -k


kcachegrind callgrind.out.*


share|improve this answer

There is also LTTng (http://lttng.org/) I've never used that one though, so I cannot tell how well it works. But one advantage it has is an userspace tracer. In some situations that could be rather nice to have.

share|improve this answer

Don't forget the poor man's profiler which is basically a wrapper for gdb so it can do sampling of where the threads "are" every so often. Basically it uses gdb to get the stacktraces for sampling, instead of lsstack, etc.

A little unrelated, but gprof itself can do sampling profiling, as well: Use callgrind as a sampling profiler? ("Flat profile is based mainly on sampling")

And you can also use a USR1 signal et al to dump thread backtraces

share|improve this answer
+1 on general principles. There are many ways to get stack samples. The difference is in what then is presented to the user. Nearly every profiler concentrates on getting the samples, but treat the presentation as little more than eye candy. The real value comes when you personally study a sample and everything it is telling you. If you do that for 10 at random, then you see what needs fixing. Then you realize the other 100s or 1000s of samples didn't provide any additional useful information. So then maybe you see what's broken about our whole concept of profiling. –  Mike Dunlavey Jun 21 '12 at 17:25
I use(d) FlamGraph with either the poor man's profiler or perf ans it works great. Its quite flexible, ignoring "boring" parts of the program is as easy as inserting a "grep -v" before generating the graph. –  ysdx Mar 27 at 11:40

The PCT profiler takes the stack sampling approach advocated by other responders who did not suggest a specific tool.


It can do instruction-level or procedure-level profiling. I have used it to profile non-C code in addition to C code (I have used it previously for Ocaml with interesting results).

share|improve this answer

Use SysProf; It's pretty good in doing quick profiling with minimum hassle. It shows information like how many times a function has been called, time spent in each routine, overall time spent for each function, etc. Just install, do the initial configuration and then run your application/service (no need to recompile, instrument your code).

share|improve this answer
What does instrument your code mean? –  Tshepang Sep 23 '13 at 15:06
@Tshepang Some profiling tools (Ex Valgrind) make a custom build where they add [instrumentation][1] so that they can spot buffer overflows, memory corruption easily, with the downside being that the program is dead slow to run. [1]: en.wikipedia.org/wiki/Instrumentation_(computer_programming) –  Sak Oct 8 '13 at 8:13

You can try out AMD CodeXL's CPU profiler. It is free and available for Linux.

AMD CodeXL's CPU profiler replaces the no longer supported CodeAnalyst tool (which was mentioned in an answer above given by Anteru).

CodeXL supports several CPU profiling techniques for AMD CPUs (for non-AMD CPUs, only time based CPU profiling is supported).

For more information and download links, visit: AMD CodeXL web page.

share|improve this answer


For CPU bound applications:


For IO bound applications:



If you don't have a profiler, use the poor man's profiler. Hit pause while debugging your application, most developer suites will break into assembly with commented line numbers. You're statistically likely to land in a region that is eating most of your CPU cycles.


For IO bound, the profiler can still identify I/O operations in RELEASE mode because IO operations are externally linked. I/O operations, and any statically linked operation for that matter, are not in-lineable function calls and are plain human-readable english.

share|improve this answer

Use a profiler as most people suggest. I would recommend Very Sleepy. Be aware that Visual Studio has a built in profiler itself but depended on the sampling method you may profile CPU or I/O operations.

share|improve this answer
Very Sleepy and VS are Windows only. For C++ Linux profiling try Allinea MAP, gprof, Intel Vtune, or Callgrind. –  David Dec 21 at 23:36
