使用dotTrace时，我必须选择一个分析模式和一个时间测量方法。 Profiling modes是：
跟踪和逐行不能使用线程时间测量。但这仍然让我有七种不同的组合尝试。我现在已经十几次阅读了这些关于dotTrace的帮助页面了，而且我仍然没有比我开始选择哪一个更有见识。
我正在开发一个阅读Word文档的WPF应用程序，提取所有段落和样式，然后遍历提取的内容以挑选出文档部分。我试图优化这个过程。 （目前完成需要一个多小时，因此我试图在给定的时间内对其进行分析，而不是直到完成。）
哪种分析和时间测量类型会给我最好的结果？或者，如果答案是＆＃34;它取决于＆＃34;，那么它依赖于什么？给定的分析模式或时间测量方法的优缺点是什么？
答案 0 :(得分：6)
分析类型：
采样：最快但最不准确的分析类型，最小分析器开销。基本上相当于每秒多次暂停程序并查看堆栈跟踪;因此，每种方法的呼叫数量是近似值。对于识别方法级别的性能瓶颈仍然有用。
在采样模式下捕获的快照在磁盘上占用的空间要少得多（我想减去5-6个空间。） 用于初始评估或分析长期运行的应用程序（听起来像你的情况。）
跟踪：记录每种方法的持续时间。分析中的应用程序运行速度较慢，但作为回报，dotTrace显示每个函数的确切调用次数，并且函数计时信息更准确。这有助于深入了解方法级别的问题细节。
逐行：以每行为基础对程序进行配置。最大的资源占用，但最精细的分析结果。减慢程序方式。这里首选的策略是首先使用其他类型进行分析，然后手工挑选函数进行逐行分析。
至于仪表种类，我认为它们在{Had Hariri的Getting started with dotTrace Performance中得到了很好的描述。
待机时间（CPU指令）：这是测量待机时间的最简单，最快捷的方式（即 我们在挂钟上观察的时间）。但是，在一些较旧的多核处理器上，这可能会产生 由于核心定时器不同步导致错误的结果。如果是这种情况，建议使用 使用性能计数器。
待机时间（性能计数器）：性能计数器是Windows API的一部分，它允许 以与硬件无关的方式获取时间样本。但是，作为API调用，每个度量都需要 大量时间，因此对配置文件的应用程序产生影响。
线程时间：在多线程应用程序中，并发线程会占用彼此的挂起时间。 为了避免这种干扰，我们可以使用线程时间计，它使系统API调用得到 OS调度程序给予线程的时间量。缺点是花费时间 样本比使用CPU计数器慢得多，精度也受到大小的限制 线程调度程序使用的量程（通常为10ms）。仅在分析时支持此模式 类型设置为采样
然而，他们并没有太大差异。
我不是自我描述的向导，但在你的情况下，我会先从采样开始，得到一个执行起来非常漫长的函数列表，然后我将它们标记为逐行分析。