【发布时间】：2017-07-27 11:21:04
【问题描述】：
抱歉，我无法创建一个最小的完整示例，因为该问题仅发生在相对较大的程序中，我不确定这甚至是一个“错误”本身，而不是对 callgrind 分析应该完成的误解.
我有一个大程序，它的运行时间被分成大约 50 50 成 2 个连续的部分。第一部分主要是文件读取，第二部分主要是计算。
我期望的函数调用顺序如下：
调用范围，被调用者
主要 Part1_main
Part1_main Part1_main_subfunction_1
Part1_main Part1_main_subfunction_2
Part1_main Part1_main_subfunction_3
主要 Part2_main
Part2_main Part2_main_subfunction_1
Part2_main Part2_main_subfunction_2
..
..
当我在代码上运行 callgrind （然后在 osx 上查看 kcachegrind 中的结果）时，我得到了一些关于函数调用的结果，这些结果与您所期望的大致相同，除了一件事：内部没有函数调用的解析第二部分：profile输出定性相同
函数、Pct_time、Self_time
Part1_main 50 4
Part2_main 50 50
Part1_main_subfunction_1 20 4
Part1_main_subfunction_2 15 5
..
..
..
第二个函数的自时间非常高的解释是什么？分析器似乎认为它没有调用任何其他函数。我认为函数 2 中的所有内容都有可能（尽管不太可能）是内联的，所以也许不应该有任何进一步的解决方案。如果这是真的，这不会产生非常有趣的分析结果。
如果您遇到这种类型的事情，您如何强制分析器显示进一步的分辨率？或者，如果我的直觉是错误的，还有什么可能导致这种行为？
根据 callgrind 网站的说明，我正在使用 -g 标志进行编译，并开启了优化。
【问题讨论】：
-
如果内联是导致 Part2 main 的 self 成本如此之高的原因，那么 kcachegrind 将在源代码视图选项卡中显示，因为它显示内联源代码。现在 osx valgrind 端口的质量水平可能与 linux 端口不同。此外，osx 上的内联调试信息可能并不准确。你可以在 linux 上试试看它的表现。