80

I need to profile some code running C++ on Linux. Can you guys recommend some profilers?

Falaina
  • 6,625
  • 29
  • 31
shergill
  • 3,738
  • 10
  • 41
  • 50

9 Answers9

38

Use gprof.

Just compile with -pg flag (I think (but am not sure) you have to turn of optimizations though.) and use gprof to analyze the gmon.out file that your executable will then produce.

eg:

gcc -pg -o whatever whatever.c

./whatever

gprof whatever gmon.out

Same thing with g++ and cpp.

user
  • 5,335
  • 7
  • 47
  • 63
smcameron
  • 2,547
  • 1
  • 19
  • 12
  • 33
    Profiling unoptimized code is a bit pointless, isn't it? Similarly, profiling code that has been heavily modified with -pg often misguides you into optimizing the wrong spots. – federal Jan 05 '12 at 15:44
  • 1
    -pg is a linker option, not compiler – Slug Pue Mar 18 '18 at 16:19
24

valgrind is a well-know linux profiler

dfa
  • 114,442
  • 31
  • 189
  • 228
  • thought valgrind was more for memory leak checking.. I am trying to see which functions are getting called etc – shergill Jul 22 '09 at 23:07
  • 14
    use the suite tool called "callgrind" – dfa Jul 22 '09 at 23:08
  • 2
    Valgrind is simply a framework for building dynamic tools. Although, it's become synonymous with Memcheck, a tool built on Valgrind. Callgrind is a pretty good at profiler. – Falaina Jul 22 '09 at 23:10
  • http://valgrind.org/docs/manual/cl-manual.html – xaxxon Jan 26 '17 at 07:39
13

Zoom from RotateRight ( http://www.rotateright.com ) is what I've been using. It has a butterfly view of functions and you can double-click any function to dive into source or asm code. Build with debugging information (-g) to see your source, but you should still build and profile optimized code.

XWare
  • 193
  • 1
  • 4
  • 1
    Just gave this program a shot, it's really quite nice! Currently my favorite profiler on Linux; however it's worth mentioning that it requires code to be built with `-fno-omit-frame-pointer` to effectively profile. – Nik Reiman Mar 20 '15 at 09:05
  • 1
    The link seems dead. Does anyone know where (or if) it can be found elsewhere? – Simon F Jun 16 '17 at 12:07
12

I'm a fan of Oprofile. It involves installing a kernel module and has a bit of a learning curve to it, but it's fairly powerful and works very well for optimized programs/programs without debugging symbols.

Vtune is another very powerful profiler made by Intel. I believe the Linux version is free for Non-commercial software.

There is also the Valgrind suite of tools proposed by dfa. Callgrind would probably be what you're most interested in. Cachegrind(whose featureset is a subset of Callgrind's) and Massif are interesting as well, but I have no experience with the latter.

Falaina
  • 6,625
  • 29
  • 31
5

Google also has a nice profiler as part of the google-perftools -- which are included in Debian / Ubuntu and possibly other distros.

Alcaro
  • 1,664
  • 16
  • 21
Dirk Eddelbuettel
  • 360,940
  • 56
  • 644
  • 725
5

Take a look at KCacheGrind which is a graphical frontend to valgrind and makes it really easy to use it.

Milan Babuškov
  • 59,775
  • 49
  • 126
  • 179
2

gprof is the standard gnu tool for profiling.

twk
  • 16,760
  • 23
  • 73
  • 97
2

Take a look at Sysprof. You distribution most likely has it available already.

Note that all of the mentioned profilers work best if your application is compiled with frame pointers. That is, you should use -fno-omit-frame-pointer on the gcc command line.

Søren Sandmann
  • 539
  • 3
  • 3
0

This is what I use.

Community
  • 1
  • 1
Mike Dunlavey
  • 40,059
  • 14
  • 91
  • 135
  • you'll just base your judgement about the bottleneck on 10 samples you collect manually, instead of 1000 samples collected by `prof`. – Dmitry Grigoryev Jan 05 '21 at 21:49
  • 1
    @DmitryGrigoryev: Correct, and that actually tells you what you should fix. The statistical explanation is [*here*](https://scicomp.stackexchange.com/a/2719/1262). In fact, the first mistake people make is to think that they are looking for a "bottleneck" rather than perfectly good but wasteful code ;-) – Mike Dunlavey Jan 06 '21 at 19:41
  • Nice read, thanks. I totally buy your point that optimizing is way easier when you see an actual function call in the debugger. And I do understand that "bottleneck" doesn't mean "good optimization target", just a potential one. Still, I think it makes sense to start with `prof` anyway: if I see that `f()` is the most problematic function statistically, I'll stop the program several times until I land in `f()` instead of just starting with a random function I stopped in first. – Dmitry Grigoryev Jan 06 '21 at 21:26