使用dotTrace时，我必须选择一种分析模式和一种时间测量方法。分析模式为：
- 跟踪
- 逐行
- 采样
时间测量方法有：
- 壁时间（性能计数器）
- 线程时间
- 壁时间（CPU指令）
跟踪和逐行不能使用线程时间测量。但这仍然让我有七种不同的组合可以尝试。我现在已经读了十几遍关于这些的dotTrace帮助页面，而且我对选择哪一个并不比刚开始时更了解。
我正在开发一个WPF应用程序，它可以读取Word文档，提取所有段落和样式，然后循环提取的内容来挑选文档部分。我正在努力优化这个过程。（目前它需要一个多小时才能完成，所以我试图在给定的时间长度内对它进行分析，而不是直到它完成。）
哪种分析和时间测量类型会给我最好的结果？或者，如果答案是"取决于"，那么它取决于什么？给定的评测模式或时间测量方法的优缺点是什么？
分析类型：
-
采样：最快但最不准确的分析类型，最小的分析程序开销。本质上相当于每秒暂停节目多次并观看堆栈竞赛；因此每个方法的调用次数是近似的。对于在方法级别识别性能瓶颈仍然有用。
在采样模式下捕获的快照占用的磁盘空间要小得多（我认为空间要小5-6个）用于初始评估或分析长时间运行的应用程序时（听起来像您的情况。）
-
跟踪：记录每种方法的持续时间。评测中的应用程序运行速度较慢，但作为回报，dotTrace显示每个函数的确切调用次数，函数计时信息更准确。这有利于在方法级别深入研究问题的细节。
-
逐行：按行配置程序。最大的资源占用，但最细粒度的分析结果。以的方式减慢程序。这里的首选策略是首先使用另一种类型进行评测，然后手动选择函数进行逐行评测。
至于米的种类，我认为它们在伟大的哈迪·哈里里的《开始使用dotTrace性能》中描述得很好。
壁时间（CPU指令）：这是测量壁时间的最简单、最快的方法（即我们在挂钟上观察的时间）。然而，在一些较老的多核处理器上，这可能会产生由于核心定时器被取消同步而导致的错误结果。如果是这种情况，建议使用性能计数器。
墙时间（性能计数器）：性能计数器是Windows API的一部分，它允许以独立于硬件的方式获取时间样本。然而，作为一个API调用，每一个度量都需要相当长的时间，因此对所描述的应用程序有影响。
线程时间：在多线程应用程序中，并发线程会增加彼此的墙时间。为了避免这种干扰，我们可以使用线程计时器，它会调用系统API来获取OS调度器给线程的时间量。缺点是占用线程时间采样比使用CPU计数器慢得多，精度也受到线程调度程序使用的量子（通常为10ms）。只有在分析类型设置为采样
然而，它们并没有太大的差异。
我自己不是一个分析向导，但在您的情况下，我会从采样开始，得到一个执行时间长得离谱的函数列表，然后我会将它们标记为逐行分析。