分析器报告的时间与真实时间——为什么会有差异

Timings reported by profiler vs true timings - why the discrepancy?

本文关键字：时间为什么真实报告分析器更新时间：2023-10-16

我有两段代码执行相同的操作。一块是我自己写的，另一块是第三方写的。它们都被编译成一个可执行文件。第三方代码似乎比我的代码完成工作要快得多。它每秒可以执行1500次操作，而我每秒只能执行500次。然后我在VTune中运行可执行文件，使用callgraph profiling选项，希望这能揭示我浪费时间的地方。不幸的是，VTune诊断显示了它认为每个函数所花费的微秒数，它声称我的函数和第三方函数每次调用大约花费0.002秒。这对我的代码来说似乎是正确的，但与我对第三方代码的速度(手动)测量完全不一致。

怎么会这样?

编辑:两个代码块都很大，并且调用它们自己的子函数的复杂树。

编辑:我应该指出第三方代码是纯c++的，而我的代码本质上是C代码，刚刚在c++编译器中编译。

编辑:VTune是一个非常复杂的软件包，有很多我不理解的配置选项。是否有一些设置可以减少这种不准确性?

你对"真计时"的定义可能需要修改了。当比较苹果和梨时，你不能说分析器是错误的。

分析器可用于相对计时;使用分析器查找代码中的"热点"，然后使用该信息对该区域进行优化。

一个实用的注意事项:寻找一个采样分析器，它通常比跟踪/检测分析器的开销/影响要小得多

(PS 还要阅读薛定谔/海森堡)

我看到过分析器人为地夸大某些函数/系统调用的报告时间的情况。这可能是第三方库正在使用一些这样的调用并与之挂钩。

您是否尝试过使用高性能时钟(Solaris中的gethrtime或Windows中的QueryPerformanceCounter)并测量函数的总时间作为完整性检查?

你的操作听起来真的很慢CPU限制-他们是I/O限制?您的I/O代码是否不如库的优化?这根本不需要在CPU配置报告中显示。

如果您正在使用隔离时间(即，用经过的秒数而不是CPU计数器)，您还需要考虑阻塞系统调用所花费的时间。例如，假设您没有做太多的文件I/O，那么您可能会花费大量时间将信息打印到控制台。控制台I/O不会显示为CPU时间，因为大部分时间只是等待更新控制台。

您可以使用GetThreadTimes(...)来确定您在代码和系统代码上花费了多少时间。我已经使用这个和系统调用采样来减少上下文切换(并最终提高整体性能)。