注意:在做基于VS2005 开发的网站分析的时候,dottrace 必须打开IIS的对应该的网站,他不能打开VS2005 打开的程序
性能分析(Performance Profiling)：在dotTrace中在被测试程序中当某些特定操作持续的时间.可以
- 定位运行最慢的代码(Locate the slowest-running parts in your co
de) - 找出性能瓶颈的制约(Identify performance bottlenecks down to any particular function)
- 观察单个函数花费的CPU时间(Focus on a function to see what makes it consume CPU time)
- 理清复杂的递归调用(Untangle complex recursive calls)
- 比较前后时序优化功能(Compare function timings before and after optimization)
性能分析包括几个分析方法，每一个都有其特定的用途。
-
跟踪分析 vs 抽样分析(Tracing Profiling vs Sampling Profiling)
-
Measuring Wall Time vs Thread Time
-
即时内联
内存分析:衡量分配的内存量和应用程序的对象释放。可以：
- 获取有关内存使用全面统计
- 查看哪些类和消费最多的内存空间
- 确定举行可达对象为某对象
- 分析源垃圾发电
会话分析:在同一段时间内的分析的应用程序的不同方面。分析会话可通过dotTrace用户界面，或命令行或API运行
快照:是一个文件，包含由dotTrace分析期间保存的数据,用视图表示。这些数据包括等参数：
- 函数的执行时间
- 函数调用次数
- 函数占总花费时间的百分比
- 对象包含类的个数
- 对象分配的内存
- 拥有的对象个数
- 占用的内存
快照视图:是一个快照数据的可视化表示（期间收集到的分析会话）,可从不同角度分析结果。 dotTrace提供了几视图
- 性能分析视图
- 调用树视图:树般的呼吁所有可执行的功能分组分析会话期间，他们可以通过线程或所有线程分组
- 平面视图:查看会话期间所有方法或函数调用
- 热点视图:查看会话期间时间花费最多的函数和方法
- 反向视图:查看调用选定函数的函数
- 内存分析视图
- 类列表:内存分析的的默认视图,准确统计对象的数量和程序中各个类分配的内存量
- 命名空间树:按命名空间分组对象
- 外引用:显示引用外部对象的对象引用
- 内引用:显示对该对象的引用
- 分配树:以树结构显示分配到该对象的函数。
过滤：显示或隐藏特定函数。请参阅创建和应用过滤器。
打开独立的标签窗口：对于CPU快照，可以为一个函数打开一个新的标签窗口来显示函数花费CPU的时间率；对于内存快照，可以分析内存查看引用，查看静态数据等。Opening in a New Tab
为CPU快照，另开一个新标签上显示的功能是指一个函数，作为一个消耗100％的资源根源的CPU一定比例的信息。
内存快照，揭开了新标签组对象使您可以分析内存：鉴于参考，研究统计等
见打开在新标签。
折叠
dotTrace因此可以折叠递归调用，过滤来电。
折叠递归调用帮助用户有效地分析递归算法的性能。见折叠递归调用。
折叠式过滤要求，确定可以在代码的部分，感兴趣的用户的性能瓶颈。见折叠滤波呼吁。
垃圾收集器
垃圾回收器回收的企图是不会被应用程序使用的对象使用的内存。见显示垃圾信息。
举行可达的对象
一个对象是持有另一个对象，如果它仍然未引用时，引用对象被删除。举行内存是由持有对象分配的内存量。
可到达的对象是从另一个对象，如果存在一些应用程序中的名称，导致它，直接或通过其他到达对象的引用。
见查看举行可达的对象。
种对象
活动对象：对象，在得到一个内存快照的时刻存在。
新的对象：对象不存在时，内存的标志，而是由获得快照那一刻出现。
死对象：对象时存在内存的标志，而是由获得快照那一刻死亡。
垃圾：对象的分配和内存之间的标识和获取快照垃圾收集器收集。
最后确定的对象：对象的定稿（处置终结）（见最后审定并最终确定对象）。
见差异获取内存国模式，在内存中筛选国家和查看最终确定对象的差异。
最后审定并最终确定对象
解释确定物体的概念，让我们定义定稿。当从根不强引用仍然是一个对象，并在垃圾收集器收集它，该对象可最后定稿。在。NET，对象只有在完成覆盖Object.Finalize（）方法。
注意：在C＃中有没有办法覆盖Object.Finalize（）方法。相反，它可以创建一个析构函数。在编译时，编译器创建一个方法，载有析构函数，它调用的Finalize（）基类的方法，然后执行析构函数的代码。
然而，使用析构函数的缺点是，他们是在一个不确定的时间要求。因此，它不是一个析构函数，而是Dispose（）方法，通常用于为那些不再需要免费资源。在Dispose（）方法被调用，你应该当你不再需要的对象。如果你忘记调用它时，该方法将调用相应的Finalize（）方法。然而，这是一个不好的做法留给到终结，因为在性能较低，效益低的应用程序的内存使用此结果。
为了解决这一问题，dotTrace可以检测到定稿对象。对于其中的一些，你会发现，他们没有明确处理在您的代码。
从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。
