Can anybody recommend a good code profiler for C++?
I came across Shiny - any good? http://sourceforge.net/projects/shinyprofiler/
+5
A:
Not C++ specific, but AMD's CodeAnalyst software is free and is feature-packed.
http://developer.amd.com/cpu/codeanalyst/codeanalystwindows/Pages/default.aspx
moogs
2008-10-27 12:45:15
The DevPartner link don't point on the product page (it's redirected). I can't find the product page for DevPartner...
Klaim
2009-06-01 13:00:34
Try archived page: http://web.archive.org/web/20070927222542/http://www.compuware.com/products/devpartner/default.htm
Helen
2009-06-01 18:03:52
+2
A:
If you are running a Professional version of VS then you get a profiler with it.
I've also used a couple of other free ones, but they don't compare to the on MS ships. Useful as a second opinion though.
graham.reeds
2008-10-27 13:23:19
Actually, at least in VS2008 you don't get a profiler with the Pro edition - you have to get the next one up (Team edition or something like it).
Timo Geusch
2008-10-27 13:28:30
Ah. I've not used VS2008 in anger. Some of us are stuck maintain legacy apps in VC6.
graham.reeds
2009-03-19 13:15:25
+2
A:
Quantify (part of the IBM/Rational PurifyPlus package) is a very good profiler, but not exactly cheap. It is available on several platforms, too - I've used it on Solaris, Windows and Linux.
Timo Geusch
2008-10-27 13:29:41
+5
A:
Probably you will be interested in Intel VTune. Rather useful and allows to collect low-level events like cache misses which helps a lot in tuning.
+5
A:
Gprof if you use gcc. It may not be user friendly but still useful.
artificialidiot
2008-10-27 13:59:28
A:
If you have access to a Mac, then I recommend using Shark from the CHUD tools.
ceretullis
2008-10-27 16:02:24
A:
You can use the analyzer that´s in Sun Studio 12 on Linux or Solaris. Itś free. http://developers.sun.com/sunstudio/index.jsp
tpgould
2008-10-28 18:52:56
+1
A:
Depends on what you need to do:
- Measure, so you can do regressions testing to see if changes in performance happened.
- Find reasons for suboptimal performance and optimize them.
These are not the same.
For 1, use one of the recommended profilers.
For 2, the profiler I much prefer is one you already have:
http://www.wikihow.com/Optimize-Your-Program%27s-Performance
To see how this goes, check this out.
For C++, as for C# and any language that encourages layers of abstraction, those layers may or may not be good from a software engineering standpoint, but they can kill performance. Every method call is a detour in the execution of your program, and the style encourages you to nest those things, sometimes needlessly. Also the style discourages you from knowing or caring what goes on inside them. You may find them creating and deleting objects underneath at a rate and level of generality far beyond what your application really needs.
Mike Dunlavey
2009-03-09 17:13:24
More often than not, the addition of a function call on the stack will not decrease performance. This is usually one of the many traps that people fall in to when prematurely optimizing their code.
Jared
2009-05-26 18:38:12
Mike Dunlavey
2009-05-26 18:58:36
... another way to put it: optimizers sweat bullets to shave a few low-level instructions like add, move, jump, etc. If they could also do a good job of shaving call instructions, think of the awesome savings. But, for better or worse, that's not the compiler's job, it's ours.
Mike Dunlavey
2009-05-26 19:12:13
... sorry, can't resist. Another way to put it is function calls are at the heart of the powerful concept of abstraction. The price of that power is that they tempt us powerfully to make mountains out of molehills. We programmers haven't really learned how to resist that temptation.
Mike Dunlavey
2009-05-26 19:17:20
... yet another way to put it :-) A function call is like a credit card. What is the cost of a credit card? Some plastic, some processing, some marketing - maybe a dollar. The TRUE cost is it's so easy to use that you spend more than you can afford. Multiply this over several layers, and you can see the problem.
Mike Dunlavey
2009-06-01 12:37:04