Where can I find a profiler for C# applications to be used in Visual Studio 2008?

Question

I\'m looking for a profiler for my C# application being developed in Visual Studio 2008. I am looking for something that is inexpensive (open sourced is preferred) and that it c

Answer 1

For performance tuning, as opposed to memory diagnostics, there's a simple way to do it.

It's counterintuitive, but all you have to do is run the program under the IDE, and while it's being slow, pause it several times, examining the call stack to see why it's doing whatever it's doing. Chances are excellent that multiple samples will show it doing something that you could eliminate. The time saved is roughly equal to the fraction of samples that contained the code you fixed.

It is "quick and dirty", but unlike most profilers, it pinpoints the actual statements needing attention, not just the functions containing them. It also gives directly a rough estimate of the speedup you can expect by fixing them. It is not confused by recursion, and it avoids the call-tree difficulty that a problem might be small in any branch, but could be big by being spread over many brances.

I take several samples N, usually no more than 20. If there is a hotspot or a rogue method call somewhere mid-stack, taking some fraction F of the execution time, then the number of samples that will show it is NF +- sqrt(NF(1-F). If N=20 and F=0.15, for example, the number of samples that will show it is 3 +- 1.6, so I have an excellent chance of finding it.

Often F is more like 0.5, so the number of samples showing it is 10 +- 2.2, so it will not be missed.

Notice this has absolutely nothing to do with how fast the code is, or how often it runs. If optimizing it will save you a certain percentage of time, that determines what percentage of samples will display it for you.

Usually there are multiple places to optimize. If problem 1 has F1=0.5, and problem 2 has F2 = 0.1, then if you fix problem 1 (doubling the program's speed), then F2 usually increases by that factor, to 0.2. So you can do it again and be sure of finding problem 2. In this way, you can knock down a succession of problems, until the code is practically optimal.