|C++ runtime profiling firstname.lastname@example.org (Amit Gupta) (2007-06-22)|
|Re: C++ runtime profiling email@example.com (David Z Maze) (2007-06-25)|
|Re: C++ runtime profiling firstname.lastname@example.org (Russ Cox) (2007-06-25)|
|Re: C++ runtime profiling email@example.com (regan) (2007-09-04)|
|C++ runtime profiling firstname.lastname@example.org (Michael Dunlavey) (2012-01-13)|
|From:||David Z Maze <email@example.com>|
|Date:||Mon, 25 Jun 2007 11:24:55 -0400|
|Organization:||Massachusetts Institute of Technology|
|Posted-Date:||25 Jun 2007 11:30:10 EDT|
Amit Gupta <firstname.lastname@example.org> writes:
> I wonder if there are other good open-source runtime profilers for C+
> +. My minimal knowledge indicates either gprof and to some extent
> cachegrind (little different). What other tools are out there? Is
> gprof the best out there for free profilers? Please, open-source and
> free tools are important keywords in my message.
oprofile  is a very useful whole-system profiling tool, particularly
if you're using 32-bit x86 Linux. It can identify which processes are
using the most CPU cycles, and can drill down as far as individual
instructions. You can also set it to look for specific other things
(e.g. branch mispredicts). The upside is that you can run unmodified
code under it; the major downsides are requiring Linux kernel support
and not being able to gather exact call-profile statistics (gprof I
belive logs every call in addition to taking periodic samples).
You mention cachegrind; I wouldn't even attempt to use any of the
greater valgrind tool suite for any sort of performance testing, since
it works by emulating the entire machine with hooks for plug-ins to do
extra work, most frequently checking that memory accesses refer to
initialized memory. If you're sure that cache misses are your
performance problem it might be helpful, but I don't know how you'd
determine that without starting with a broader profiler.
Return to the
Search the comp.compilers archives again.