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

如何解决分析器报告的时间与真实时间-为什么会有差异？

| 我有两个代码块执行相同的操作。一个由我自己编写，另一个由第三方编写。它们都被编译成单个可执行文件。第三方代码似乎比我的要快得多。与我的500个相比，它每秒可以执行1,500个操作。然后，我在VTune中运行了可执行文件，并使用了调用图分析选项，希望这可以显示我在浪费时间。不幸的是，VTune诊断程序显示了它认为每个功能花费的微秒数，声称我的功能和第三方功能每次调用大约花费0.002秒。这对于我的代码来说似乎是正确的，但与我（手动）对第三方代码速度的度量完全不符。 怎么会这样 编辑：这两个代码块都很大，并调用了它们自己的子函数复杂树。 编辑：我应该指出，第三方代码是纯C ++，而我的代码本质上是刚刚在C ++编译器中编译的C代码。 编辑：VTune是一个非常复杂的程序包，其中包含许多我不了解的配置选项。可能需要进行一些设置以减少这种不准确性吗？

解决方法

您对“真实时间”的定义可能需要修改。在比较苹果和梨时，您不能断言分析器是错误的。 探查器可以用于相对计时；使用探查器在代码中找到“热点”，然后使用信息来优化该区域。 在实践上，请注意：寻找一个采样探查器，它通常比跟踪/仪表探查器具有更少的开销/影响 （PS另请阅读Schrodinger / Heisenberg）,我已经看到了一些情况，其中探查器人为地增加了某些功能/系统调用的报告时间。可能是第三方图书馆正在使用这样的调用并被固定。 您是否尝试过使用高性能时钟（在Solaris中为

gethrtime

，在Windows中为

QueryPerformanceCounter

）并测量功能的总时间以进行健全性检查？ 受CPU限制，您的操作听起来真的很慢-它们是否受I / O限制？您的I / O代码是否比库的优化程度低？这不一定会显示在CPU配置文件报告中。,如果您使用的是墙上时间（即经过的秒数而不是CPU计数器），则还需要考虑阻塞系统调用所花费的时间。例如，假设您没有做太多的文件I / O，则可能要花费大量时间将信息打印到控制台上。控制台I / O不会显示为CPU时间，因为大部分时间只是在等待更新控制台。 您可以使用

GetThreadTimes(...)

来确定您花费在代码与系统代码上的时间。我已经使用它和系统调用采样来减少上下文切换（并最终提高整体性能）。