使用 dotTrace 时,我必须选择分析模式和时间测量方法。 Profiling modes是:
和time measurement methods是:
跟踪和逐行不能使用线程时间测量。但这仍然让我有七种不同的组合可以尝试。我现在已经阅读了十多次关于这些的 dotTrace 帮助页面,但我仍然没有比我开始选择哪个更了解。
我正在开发一个 WPF 应用程序,该应用程序读取 Word 文档,提取所有段落和样式,然后遍历提取的内容以挑选文档部分。我正在尝试优化这个过程。 (目前它需要一个多小时才能完成,所以我试图在给定的时间长度内对其进行分析,而不是直到它完成。)
哪种分析和时间测量类型会给我最好的结果?或者如果答案是“取决于”,那么它取决于什么?给定的分析模式或时间测量方法的优缺点是什么?
最佳答案
分析类型:
以采样模式捕获的快照占用的磁盘空间要少得多(我会说少 5-6 个空间。)
用于初始评估或分析长期运行的应用程序(听起来像您的情况。)
至于仪表种类,我认为它们在Getting started with dotTrace Performance 中描述得很好。由伟大的哈迪哈里里。
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
然而它们并没有太大的不同。
我不是分析自己的向导,但在你的情况下,我会从采样开始以获得执行时间非常长的函数列表,然后我会将它们标记为逐行分析。
关于performance - dotTrace - 我应该为我的桌面应用程序使用哪些分析设置?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/9572710/