我无法分享整个代码库以重现问题,但是我正在使用Visual Studio Diagnostic Tools来检查性能,然而操作却需要执行比CPU使用率报告的时间长多了。
示例代码
这里是两个断点之间容易出错的代码块的示例:
分析时间
此方法内部的CPU采样仅显示它花费了约1000毫秒来执行:
执行时间
然而,在两个断点之间需要近50秒才能完成
问题
- 什么可能导致如此长的执行时间线,而在分析中没有显示出来?
我尝试过的事情:
- 重新启动VS
- 重新启动机器
- 重新加载符号
- 缓存符号
我无法分享整个代码库以重现问题,但是我正在使用Visual Studio Diagnostic Tools来检查性能,然而操作却需要执行比CPU使用率报告的时间长多了。
这里是两个断点之间容易出错的代码块的示例:
此方法内部的CPU采样仅显示它花费了约1000毫秒来执行:
然而,在两个断点之间需要近50秒才能完成
实际上,我并不经常使用性能分析工具。但是,总CPU时间与总执行时间不相等听起来很有趣。我进行了搜索,并希望分享我的发现和思考过程。
我查看了这里,但没有找到太多信息。然后我在这里找到了一个非常有趣的观点。正如您下面所看到的文档包括一个演示,显示像您一样的CPU Usage
选项卡。但是,有[External Call]
标记的函数并不是微不足道的。文档说明:
外部代码是系统和框架组件中由您编写的代码执行的函数。外部代码包括启动和停止应用程序、绘制UI、控制线程和为应用程序提供其他低级服务的函数。在大多数情况下,您不会对外部代码感兴趣,因此CPU使用工具将用户方法的外部函数收集到一个[External Code]节点中。
由于您的示例未包含此函数,因此可能会在执行时间和总 CPU 时间之间创建此间隔。您可以查看此链接以查看 CPU 使用情况
选项卡中外部代码的调用路径。它们默认处于禁用状态。
但即使这种情况是真的,它也不能解释时间差异1000毫秒 - 50秒
。
经过一点搜索,我发现了this。另一个关于分析CPU使用情况的文档。他们正在使用的演示与您的非常相似,如下所示。即使有外部代码,也有近60秒
的差异。这就是我开始思考我们是在比较苹果和花生吗?
的地方。
总 CPU [unit, %]
。这个“unit”是什么?在上面的文档中,他们说:
总 CPU [unit, %] 所选时间范围内调用函数及其调用函数所使用的毫秒数和 CPU 百分比。这与 CPU 利用率时间轴图不同,后者将时间范围内的总 CPU 活动与总可用 CPU 进行比较。
好的,这是以毫秒为单位的,我们知道了。但它具体代表什么呢?
我搜索了很多,看到了 this post,然后被重定向到了this moldy documentation。它关于分析器仪器数据 ,并且他们说:
时间:以毫秒(msec)或处理器周期(ticks)为单位,用于直接执行此函数,不包括在此函数调用的子函数中花费的时间。
之后我查看了更多更新的文档,但是像上面引用的那样,它们只提到了毫秒。但是这份旧文档给了我启示。如果他们正在引用 CPU 周期计数,这就解释了一切。它们没有考虑空闲状态、中断、锁定和作业优先级。实际上,这是一个明智的做法。CPU 以离散方式处理函数。通过这种方式,每次都可以获得更一致的结果。
如果我的研究是正确的,我认为当您开始执行时,它会捕获函数与 CPU 所花费的时间。它不会将以下事件的持续时间添加到捕获的时间中:等待彼此的函数、等待 I/O 的函数、操作系统决定接管进程、高优先级进程接管、线程锁定、WINDOWS 更新... 即使函数的总捕获时间为 1ms
,根据计算机的不同,完成任务可能需要几分钟。CPU 执行时间是离散的,但断点之间的时间是连续的。这就是为什么它们之间有一定的余地。