为什么我的程序在 _fini 中花费了 85% 的 CPU 周期？答案

【问题标题】：Why does my program spent 85% of CPU cycles in _fini?为什么我的程序在 _fini 中花费了 85% 的 CPU 周期？
【发布时间】：2012-08-01 21:55:39
【问题描述】：

在使用 oprofile 分析我的程序后，我有点惊讶。

资料显示我的程序在_fini 上花费了 85%：

CPU：Intel Core/i7，速度 1199 MHz（估计）计数 CPU_CLK_UNHALTED 事件（未停止时的时钟周期）与一个单元 0x00 的掩码（无单位掩码）计数 100000 个样本 % 图像名称符号名称 553519 85.7402 eddic _fini

其他符号看起来不错。

我的程序是用 GCC 4.7 编译的。

据我了解，符号 _fini 是一个已弃用的全局销毁构造，所以我不明白为什么我的程序会在这个符号上花费这么多时间。

这可能是由于 oprofile 或 GCC 的错误配置造成的吗？

我尝试分析未优化的代码，但问题不存在。没有没有优化的符号。

有没有办法修复配置文件或避免在_fini 上花费这么多时间？

我不能粘贴我的粘贴，因为它很长，我没有隔离问题。

感谢您的建议

【问题讨论】：

这段时间发生了什么磁盘活动？也许它正在完成写入。此外，如果使用了大量内存，它可能会释放页面。
一些分析器让你忽略你对分析不感兴趣的函数。或者，您可以修改您的代码以在您想要分析时使用_exit()，但您的全局析构函数都不会运行。
是的，我可以尝试忽略函数，但我想知道在_fini中是否真的花费了时间，是否有显示错误或是否来自其他因素。
你能粘贴你的代码吗？也许类析构函数中有一些奇怪的东西。或者这只是分析器的问题！
我没有使用该分析器，所以我不知道它如何显示结果，但请注意，与代码其他部分具有更高时序的未优化代码进行比较可能没有什么意义。 fini 时间可能与优化中的相同，但相对于未优化的其余部分而言，它可能太小以至于它没有出现？

标签： c++ gcc destructor oprofile

【解决方案1】：

没有看到有问题的代码真的很难指出问题出在哪里，但是 _fini 时间建议使用全局变量（或在程序运行期间也存在的静态函数变量）的析构函数。我会建议 - 你检查所有全局+静态变量的类，看看它们的析构函数在做什么 - 注释掉程序中的功能，直到停止发生，以提示您在哪里花费时间 - 使用 gdb 或其他调试器检查 _fini 发生的情况。

【讨论】：

我用 gdb 测试了我的代码，它几乎没有花时间在 _fini 中。如果我中断 _fini，它会在我的程序运行结束时中断，例如在程序结束前 10 毫秒。
会不会是您的程序符号不完整，并且 oprofile 误报了 _fini 之后但没有公共符号作为 _fini 一部分的代码？
是的，这是可能的，但我怎么知道？
很难说。理想情况下，您重新编译/重新链接所有符号并使用未剥离的图像。如果这不可能，另一种方法是使用 gdb 或 objdump 找出 _fini 真正结束的位置并将其输入到分析中
要查明你是否“过去了_fini”，可以使用objdump -d反汇编程序，在输出中找到_fini。然后只需阅读程序集以确定这是否“通过”其他代码。还可以使用nm 检查_fini 的实际报告代码大小，以及分析器报告的偏移量是否确实仍在范围内。