The Visual Studio Profiler is part of Team System only. It is not included in Visual Studio Professional.
There is a free .NET profiler called nprof, but it's not released yet and it can be rather volatile. Also, there are some excellent commercial profiler's such as ANTS Profiler from Red Gate; however, these are not low cost.
If you just want to do memory profiling, the .NET Memory Profiler is excellent. It's got a trial period and small cost after that -- well worth it. If you want to spend some money, DevPartner Studio is very good.
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.
发布评论
评论（8）
我的推荐是 dotTrace。 不是免费的，个人许可证价格为 170 欧元。
http://www.jetbrains.com/profiler/index.html
My recommendation is dotTrace. Isn't free, price is 170 EUR for Personal License.
http://www.jetbrains.com/profiler/index.html
查看 EQATEC 分析器，免费且运行良好。 也适用于 ASP.NET 和 .NET CF。
Check out the EQATEC profiler, free and works pretty well. Also works for ASP.NET and .NET CF.
Visual Studio Profiler 仅是 Team System 的一部分。 它不包含在 Visual Studio Professional 中。
有一个名为 nprof 的免费 .NET 分析器，但它尚未发布，而且可能相当易挥发的。 此外，还有一些优秀的商业分析器，例如 Red Gate 的 ANTS Profiler ; 然而，这些成本并不低。
The Visual Studio Profiler is part of Team System only. It is not included in Visual Studio Professional.
There is a free .NET profiler called nprof, but it's not released yet and it can be rather volatile. Also, there are some excellent commercial profiler's such as ANTS Profiler from Red Gate; however, these are not low cost.
以下是开源 .Net 分析器 的列表。
我使用过并喜欢 Red Gate 的 Ants-Profiler，但它确实要花钱（非常值得，恕我直言）。
Here's a list of open source .Net profilers.
I have used and like the Ants-Profiler from Red Gate, but it does cost money (highly worth it, IMHO).
此 stackoverflow 线程中有一些关于 .NET 分析器的讨论。 我使用过 CLR Profiler< /a> 一些，它之前帮助我解决了软件中的一些性能问题。 可能值得一试。 Microsoft 发布了有关如何使用 CLR Profiler 的指南。
There is some discussion on profilers for .NET in this stackoverflow thread. I have used CLR Profiler some, and it has helped me take care of a few performance issues in software before. Could be worth a try. Microsoft has published a guide on how to use the CLR Profiler.
我使用 AQtime 取得了巨大成功。
正如已经提到的 ANTS 也是一个不错的选择。
I have used AQtime with great success.
As already mentioned ANTS is also a good option.
如果您只想进行内存分析，.NET Memory Profiler 非常适合。 它有一个试用期，之后的费用很小——非常值得。 如果你想花点钱，DevPartner Studio 非常不错。
If you just want to do memory profiling, the .NET Memory Profiler is excellent. It's got a trial period and small cost after that -- well worth it. If you want to spend some money, DevPartner Studio is very good.
对于性能调整，与内存诊断相反，有一个 简单的方法。
这是违反直觉的，但您所要做的就是在 IDE 下运行该程序，虽然速度很慢，但暂停几次，检查调用堆栈以了解它为什么要做它正在做的事情。 多个样本很有可能表明它做了一些您可以消除的事情。 节省的时间大致等于包含您修复的代码的样本的比例。
它“快速而肮脏”，但与大多数分析器不同，它精确指出需要注意的实际语句，而不仅仅是包含它们的函数。 它还直接粗略估计修复这些问题后可以预期的加速效果。 它不会被递归所混淆，并且它避免了调用树的困难，即问题在任何分支中可能很小，但由于分布在许多分支上而可能很大。
我采集了 N 个样本，通常不超过 20 个。如果堆栈中间某处存在热点或流氓方法调用，占用执行时间的 F 部分，则显示它的样本数为 NF +- sqrt (NF(1-F)。例如，如果 N=20 且 F=0.15，则显示该值的样本数为 3 +- 1.6，因此我很有可能找到它。
通常 F 更像是 0.5 ，因此显示它的样本数量为 10 +- 2.2，因此不会错过它。
请注意，这与代码的速度或运行频率完全无关，如果优化它会节省一定的百分比。时间，这决定了为您显示它的样本百分比。
通常有多个地方需要优化，如果问题 1 的 F1=0.5，问题 2 的 F2 = 0.1，那么如果您修复问题 1（使程序速度加倍）。 ），那么 F2 通常会按该因子增加到 0.2，因此您可以再次执行此操作并确保找到问题 2。
通过这种方式，您可以解决一系列问题，直到代码实际上是最佳的。
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.