>追踪
>逐行
>采样
time measurement methods是：
>壁挂时间(性能计数器)
>线程时间
>壁挂时间(CPU指令)
跟踪和逐行不能使用线程时间测量.但这仍然让我有七种不同的组合尝试.我现在已经十几次阅读了这些关于dotTrace的帮助页面了,而且我仍然没有比我开始知道选择哪一个更有见识.
我正在开发一个WPF应用程序,它可以读取Word文档,提取所有段落和样式,然后遍历提取的内容以选择文档部分.我正在尝试优化这个过程. (目前完成需要一个多小时,因此我试图在给定的时间内对其进行分析,而不是直到完成.)
哪种性能分析和时间测量类型会给我最好的结果？或者,如果答案是“它取决于”,那么它依赖于什么？给定的分析模式或时间测量方法的优缺点是什么？
分析类型：>采样：最快但最不准确的分析类型,最小分析器开销.基本上相当于每秒多次暂停程序并查看堆栈跟踪;因此,每种方法的呼叫数量是近似值.对于识别方法级别的性能瓶颈仍然有用.
在采样模式下捕获的快照在磁盘上占用的空间要少得多(我想减去5-6个空间.)
用于初始评估或分析长时间运行的应用程序(听起来像你的情况.)
>跟踪：记录每种方法的持续时间.分析中的应用程序运行速度较慢,但作为回报,dotTrace显示每个函数的确切调用次数,并且函数计时信息更准确.这有助于深入了解方法级别的问题细节.
>逐行：以每行为基础对程序进行配置.最大的资源占用,但最精细的分析结果.减慢程序的速度.这里首选的策略是首先使用其他类型进行配置,然后手工挑选功能以进行逐行分析.
至于仪表类型,我认为它们在Getting started with dotTrace Performance由伟大的Hadi Hariri描述得相当好.
Wall time (CPU Instruction): This is the simplest and fastest way to measure wall time (that is, the
time we observe on a wall clock). However, on some older multi-core processors this may produce
incorrect results due to the cores timers being desynchronized. If this is the case, it is recommended
to use Performance Counter.Wall time (Performance Counter): Performance counters is part of the Windows API and it allows
taking time samples in a hardware-independent way. However, being an API call, every measure takes
substantial time and therefore has an impact on the profiled application.Thread time: In a multi-threaded application concurrent threads contribute to each other’s wall time.
To avoid such interference we can use thread time meter which makes system API calls to get the
amount of time given by the OS scheduler to the thread. The downsides are that taking thread time
samples is much slower than using CPU counter and the precision is also limited by the size of
quantum used by thread scheduler (normally 10ms). This mode is only supported when the Profiling
Type is set to Sampling
但是它们并没有太大差别.
我不是一个自我描述的向导,但在你的情况下,我会先从采样开始,得到一个执行起来非常漫长的函数列表,然后我将它们标记为逐行分析.