在积极内联的情况下分析C++?

Bra*_*sen 18 c++ profiling

我试图找出我的C++程序花费时间的地方,使用gprof.这是我的困境:如果我使用我用于发布版本的相同优化设置进行编译,几乎所有内容都被内联,并且gprof告诉我,无益的是,我90%的时间花在核心例程中,其中所有内容都是内联的.另一方面,如果我使用内联禁用编译,程序运行速度会慢一个数量级.

我想知道当我的程序编译时启用内联时,从我的核心例程调用的程序花了多少时间.

我在四核Intel机器上运行64位Ubuntu 9.04.我查看了google-perftools,但这似乎不适用于x86_64.在32位计算机上运行不是一种选择.

当启用内联时,是否有人建议如何更有效地配置我的应用程序?

编辑:这是我的问题的一些澄清.如果最初不清楚,我道歉.

我想找到在我的应用程序中花费的时间.分析我的优化构建导致gprof告诉我,大约90%的时间花在main上,其中所有内容都是内联的.在剖析之前我已经知道了!

我想知道的是内联函数花了多少时间,最好不要在我的构建选项中禁用优化或内联.在使用内联禁用进行性能分析时,应用程序的速度会慢一个数量级.这种执行时间的差异是一个方便的问题,但是,我不确定使用内联禁用构建的程序的性能配置文件是否与使用内联启用的程序的性能配置文件强烈对应.

简而言之:有没有办法在不禁用优化或内联的情况下获得有关C++程序的有用的性能分析信息?

Mik*_*vey 9

我假设你想要做的是找出哪些代码行足以让你付出足够的代价来进行优化.这与计时功能非常不同.你可以比gprof做得更好.

这是一个相当完整的解释,说明如何做到这一点.

您可以手动完成,也可以使用其中一个可以提供相同信息的分析器,例如oprofileRotateRight/Zoom.

顺便说一下,内联只有在内联的例程很小并且本身不调用函数时才具有重要价值,并且如果它们被调用的行是足够活跃的时间是重要的.

至于调试和发布版本之间的数量级性能比,可能是由于许多事情,可能是也可能不是内联.你可以使用上面提到的stackshot方法来确定在任何一种情况下发生了什么.我发现调试版本可能因其他原因而变慢,例如递归数据结构验证.


小智 -1

代码运行速度较慢并不重要(当然,不考虑您的方便) - 分析器仍然会告诉您每个函数所花费的正确时间比例。

  • 也许——但话又说回来,完全有可能事实并非如此。如果将函数调用视为一棵树,那么所有子树都理所当然地从内联中平等受益。事实上,这几乎总是错误的。在某些情况下差异并不显着,但在其他情况下差异却相当显着。 (3认同)
  • 如果内联能够更好地优化核心函数(这是很有可能的),那么没有内联的分析将会产生误导。 (3认同)
  • 我不相信禁用内联编译的程序将与编译器具有疯狂内联函数的程序等效(以整体运行时为模):内联可以实现进一步的优化,例如常量传播、循环提升、循环融合, ETC。 (2认同)