How To Do Performance Profiling in Visual Studio 2

问题:

Microsoft make this piece of software called "Visual Studio 2008 Professional". I have found that there doesn't appear to be an application performance profiler or something similar in it, making it seem not so "professional" to me.

If Microsoft don't include a profiler, what are your third party options for time profiling for Visual Studio 2008? Free would be preferable, as this is for uni student purposes :P

回答1:

Personally, I use the Red Gate profiler.

Others swear by the JetBrains one.

Those seem to be the options, and there isn't much between them.

回答2:

There are a couple of free profilers, not as complete or polished as the commercial ones, but they can definately help a lot:

Eqatec - This was designed for Windows CE, but works just fine for normal applications.

Soft Prodigy Profile Sharp - This is actually an open source project written in c#, so you can tinker with it if you want.

回答3:

I use JetBrains dotTrace profiler. This is a commercial profiler. (Full disclosure: I receive a free licence as an MVP. It has proved very useful though.)

There's also the free CLR Profiler for .NET 2.0 and an article explaining how to use it.

回答4:

I use the Team System Edition. That comes with a profiler which is pretty good. There are other options out there:

• Rational Purify (there's this PurifyPlus, but dunno much)
• Intel Vtune

Hope that helps. Note: None of them are free.

Happy profiling :)

回答5:

Download the VS 2008 stand alone command line profiler http://www.microsoft.com/downloads/details.aspx?familyid=fd02c7d6-5306-41f2-a1be-b7dcb74c9c0b&displaylang=en

回答6:

RedGate ANTS profiler is not that expensive, and does the job.

回答7:

I use JetBrain's dotTrace and it works quite well.

回答8:

same answer as:

Re-edited: You asked what your options were. If your heart is set on profiling, then look for a profiler.

On the other hand, if you actually have a performance problem to find, the simple method works as well or better than nearly every profiler. I say nearly every, because in some profilers you can actually tease out what you need to know, which is the time-cost attributable to individual instructions, especially call instructions.

The time-cost of an instruction is the amount of time that would be saved if the instruction could be removed, and a good estimate of it is the fraction of call stack samples containing it. You don't need to estimate that fraction with high precision. If the instruction is on 5 out of 10 samples, it's cost is probably somewhere in the range 45% to 55%. No matter - if you could get rid of it, you would save its cost.

So finding performance problems is not hard. Just take a number of call stack samples, collect the set of instructions on those samples, and rank the instructions by the fraction of samples containing them. Among the high-fraction instructions are some that you could optimize away, and you don't have to guess where they are.

I'm simplifying somewhat, because often it is helpful to examine more state information than just the call stack, to see if some work being done is really necessary. But I hope the point is made.

People express doubt that it could work in the presence of recursion, or work on large programs. A little thought (and experimentation) shows those objections do not hold water.