从VS2005开始，就自带了一个不错的性能分析工具Performance Profiler。但是在使用的过程中，经常有程序崩溃的情况出现，特别是在分析IIS的 web程序时。在微软的论坛上，也看到很多外国的朋友报过这样的错误。所以就使用了第三方的工具dotTrace。
市面上有很多性能的Profiler工具,AQ Time，ANTS Profiler，Speed Trace Profiler.但是分析的原理跟方法论基本都是一致的。以分析IIS的web程序为例，在dotTrace中启动Profiler，它会重新启动IIS，Attach到进程中（IIS5为aspnet_wp.exe),然后运行需要分析的程序，Get Snapshot，然后我们就可以得到一个分析的结果。关键的问题是，我们如何利用结果迅速的找到性能瓶颈。
1.Hot Spots视图。这个视图根据耗时从大到小排序了所有的方法。我们可以马上发现耗时最长的方法。总共有两种情况：
1.1该方法被调用次数非常少，但是非常耗时。这时马上得出结论，该方法就是性能瓶颈。记录下来，分析代码。
1.2该方法被调用次数很多。此时就需要使用另一个视图：Back Trees
2.Back Trees视图。这个视图通常是用来分析一个被调用很多次的函数的Callee,因为一般来说，一个函数被调用多次，一般是在某一个Callee中有一个循环或者递归 ，而性能调优的入口是这个Callee函数，而不是被调用者本身。（其实Hot Spots本身也是Back Tree，只是我们可以单独把一个函数在一个Tab页中开打，然后使用Back Tree单独分析)
3.Plain List视图。有时候，我们会发现，在Hot Spots里会出现很多系统函数，比方Linq的操作，这时如果函数太多，也许对定位不方便。这时可以使用 Plan List 视图，它只显示过滤以后的函数，然后根据Own Time进行排序，找出耗时最长的函数。但是，如果一个耗时的函数都没发现，就很有可能是由于资源的操作导致性能下降，比如循环调用Linq操作，或者发送邮件一直等待等原因。
4.Call Tree视图。在dotTrace中，Call Tree中的每一个函数的子函数并不是按照调用顺序来排列的，而是根据耗时百分比来排列的。（如果要查看函数的子函数执行顺序，在Plain List中查看）。这样的话我们可以快速的定位到下一个Important Call，并且dotTrace还提供了快捷键ctrl+shift+->(右箭头)。但是Call Tree视图对于分析有个不好的地方，就是某个函数也许会在不同的分支被循环调用，这时使用Call Tree是非常难发现的，这也是Back Tree存在的意义。
另外，dotTrace4.0还有远程调试的功能，这对于调试集成环境应该是很有用的。
补：我看到CSDN有朋友说，dotTace跟踪Windows From的程序发现子函数加起来的时间跟远小于父函数的时间，那是因为dotTrace的过滤功能， 只要点击百分数前面的小图标“unfold filtered calls”，就能把所有过滤掉的函数显示出来。实际上，该朋友碰到的情况是，dotTrace过滤掉了Application.Run()函数调用的消息循环函数RunMessageLoop。
