What's your favorite profiling tool (for C++)

2020-01-23 14:56发布

So far, I've only used Rational Quantify. I've heard great things about Intel's VTune, but have never tried it!

Edit: I'm mostly looking for software that will instrument the code, as I guess that's about the only way to get very fine results.


See also:

What are some good profilers for native C++ on Windows?

21条回答
贪生不怕死
2楼-- · 2020-01-23 15:35

For Windows, I've tried AMD Codeanalyst, Intel VTune and the profiler in Visual Studio Team Edition.

Codeanalyst is buggy (crashes frequently) and on my code, its results are often inaccurate. Its UI is unintuitive. For example, to reach the call stack display in the profile results, you have to click the "Processes" tab, then click the EXE filename of your program, then click a toolbar button with the tiny letters "CSS" on it. But it is freeware, so you may as well try it, and it works (with fewer features) without an AMD processor.

VTune ($700) has a terrible user interface IMO; in a large program, it's hard to find the particular call tree you want, and you can only look at one "node" in a program at a time (a function with its immediate callers and callees)--you cannot look at a complete call tree. There is a call graph view, but I couldn't find a way to make the relative execution times appear on the graph. In other words, the functions in the graph look the same regardless of how much time was spent in them--it's as though they totally missed the point of profiling.

Visual Studio's profiler has the best GUI of the three, but for some reason it is unable to collect samples from the majority of my code (samples are only collected for a few functions in my entire C++ program). Also, I couldn't find a price or way to buy it directly; but it comes with my company's MSDN subscription. Visual Studio supports managed, native, and mixed code; I'm not sure about the other two profilers in that regard.

In conclusion, I don't know of a good profiler yet! I'll be sure to check out the other suggestions here.

查看更多
迷人小祖宗
3楼-- · 2020-01-23 15:35

The only sensitive answer is PTU from Intel. Of course its best to use it on an Intel processor and to get even more valuable results at least on a C2D machine as the architecture itself is easier to give back meaningful profiles.

查看更多
别忘想泡老子
4楼-- · 2020-01-23 15:36

The profiler in Visual Studio 2008 is very good: fast, user friendly, clear and well integrated in the IDE.

查看更多
Emotional °昔
5楼-- · 2020-01-23 15:38

My favorite tool is Easy Profiler : http://code.google.com/p/easyprofiler/

It's a compile time profiler : the source code must be manually instrumented using a set of routines so to describe the target regions. However, once the application is run, and measures automatically written to an XML file, it is only a matter of opening the Observer application and doing few clicks on the analysis/compare tools, before you can see the result in a qualitative chart.

查看更多
唯我独甜
6楼-- · 2020-01-23 15:39

IMHO, sampling using a debugger is the best method. All you need is an IDE or debugger that lets you halt the program. It nails your performance problems before you even get the profiler installed.

查看更多
乱世女痞
7楼-- · 2020-01-23 15:40

I've used VTune under Windows and Linux for many years with very good results. Later versions have gotten worse, when they outsourced that product to their Russian development crew quality and performance both went down (increased VTune crashes, often 15+ minutes to open an analysis file).

Regarding instrumentation, you may find out that it's less useful than you think. In the kind of applications I've worked on adding instrumentation often slows the product down so much that it doesn't work anymore (true story: start app, go home, come back next day, app still initializing). Also, with non instrumented profiling you can react to live problems. For example, with VTune remote date collector I can start up a sampling session against a live server with hundreds of simultaneous connections that is experiencing performance problems and catch issues that happen in production that I'd never be able to replicate in a test environment.

查看更多
登录 后发表回答