在使用 gprof 分析我编写的 C++ 程序的过程中，我注意到绝大多数执行时间都花在了函数“frame_dummy”上。更准确地说，来自 gprof 输出的平面配置文件中的第一个条目显示了 76.38% 的采样时间花费在和 24611191 次调用名为 frame_dummy 的函数上。
简而言之，我试图理解 frame_dummy 指的是什么——因为我没有任何这样命名的函数——以及这对我的优化工作意味着什么。
虽然不太可能相关，但我应该补充一点，该程序旨在使用多重网格算法求解泊松方程，并采用 MPI 来并行化任务。但是，尽管存在 MPI 函数调用，但上面提到的 gprof 输出是从仅运行单个进程中得出的。我还应该注意，我的程序除了 MPI 之外没有任何依赖项，并且是使用 g++ 4.6.1 编译的。
【问题讨论】：
我遇到了同样的问题，这是我的 gprof 输出：
% cumulative self self total
time seconds seconds calls ms/call ms/call name
52.00 16.27 16.27 204000 0.08 0.08 frame_dummy
47.46 31.12 14.85 418000 0.04 0.07 f2
0.51 31.28 0.16 21800 0.01 1.42 f1
0.03 31.29 0.01 1980 0.01 14.21 f5
就我而言，当我使用 gcc -Os 而不是 gcc -O3 编译时，它得到了解决：
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds seconds calls ms/call ms/call name
53.12 22.24 22.24 200000 0.11 0.11 f4
45.65 41.36 19.11 598000 0.03 0.03 f2
0.69 41.65 0.29 20000 0.01 1.45 f3
0.45 41.84 0.19 39800 0.00 0.32 f1
0.10 41.88 0.04 evaluate
也就是说，gprof 将 f4 误认为是 frame_dummy。
【讨论】：
这里有一个很好的解释：http://dbp-consulting.com/tutorials/debugging/linuxProgramStartup.html。但我不确定为什么你的程序会在 frame_dummy 中花费这么多时间，或者为什么它会被调用这么多次。
也许您的二进制文件中的调试信息在某种程度上已损坏，或者被 gprof 误读了？或者 gprof 可能会被 MPI 混淆？这里有一些尝试：在 gdb 中运行你的程序，并在 frame_dummy 函数上设置一个断点。看看它是否真的被调用了 2400 万次，如果是，那么它是从什么地方调用的。
另外，您能否确认这是 crtbegin.o 中的 frame_dummy，而不是其他的 frame_dummy？
这里是the source for frame_dummy in crtbegin.c——根据我阅读的代码，它应该只被调用一次。
另外，我假设您的程序运行并产生正确的结果？ （特别是，如果您的程序中存在内存错误，那么您可能会得到一些非常奇怪的行为。）
【讨论】：
-pg 选项；但将其添加到链接步骤。使用了crtbegin 和-pg；但在他的代码中没有调用 gprof 工具。
frame_dummy 时间。当 -O3 生效时，似乎较新版本的 g++ 会进行不同/更具侵略性的优化。我没有注意到 v4.4 的这个问题。切换到-Os 后，我注意到一些函数中有一些断言。当我删除断言时，这些函数变得更快，并且对 frame_dummy 没有任何贡献。
gprof 被我使用 -fopenmp 弄糊涂了，如果我删除了 OpenMP，frame_dummy 就会消失。