c++ - 为什么函数调用比根据 gprof 执行的代码花费的时间长得多？

Question

我正在学习如何使用 gprof 分析我的代码。对于我的一个应用程序，我有以下输出:

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total           
 time   seconds   seconds    calls  ms/call  ms/call  name    
 10.27      1.20     1.20                             Location::get_type() const (location.cpp:20 @ 40a4bd)

再往下看

  1.20      4.98     0.14 34662692     0.00     0.00  Location::get_type() const (location.cpp:19 @ 40a4ac)

这是函数

char Location::get_type() const {
    return type;
}

我假设 gprof 的第一行指的是函数需要执行的总时间，而第二行指的只是 return 语句所需的时间。我还有其他函数是返回 ints 的同一个类的 getter，但是函数时间和返回语句时间之间的差异只有大约 0.1 秒，而我发布的时间差是 1.06 秒(其他 getter 被调用的次数大约少了 200 万次，与调用总数相比很小)。与函数调用中的一行代码相比，有什么可以解释函数调用的更多时间？

可能值得一提的是，我使用 -g -pg 进行编译，因为我在逐行模式下使用 gprof。

编辑:其中一个答案建议我查看程序集输出。我看不懂，所以我会在这里发布。我已经发布了两个函数调用的汇编代码。第一个是 get_floor()，它相对较快(~.10 秒)。第二个是 get_type()，它很慢。

_ZNK8Location9get_floorEv:
.LFB5:
        .cfi_startproc
        pushq   %rbp
        .cfi_def_cfa_offset 16
        .cfi_offset 6, -16
        movq    %rsp, %rbp
        .cfi_def_cfa_register 6
        movq    %rdi, -8(%rbp)
        movq    -8(%rbp), %rax
        movl    8(%rax), %eax
        popq    %rbp
        .cfi_def_cfa 7, 8
        ret
        .cfi_endproc
.LFE5:
        .size   _ZNK8Location9get_floorEv, .-_ZNK8Location9get_floorEv
        .align 2
        .globl  _ZNK8Location8get_typeEv
        .type   _ZNK8Location8get_typeEv, @function
_ZNK8Location8get_typeEv:
.LFB6:
        .cfi_startproc
        pushq   %rbp
        .cfi_def_cfa_offset 16
        .cfi_offset 6, -16
        movq    %rsp, %rbp
        .cfi_def_cfa_register 6
        movq    %rdi, -8(%rbp)
        movq    -8(%rbp), %rax
        movzbl  12(%rax), %eax
        popq    %rbp
        .cfi_def_cfa 7, 8
        ret
        .cfi_endproc

Answer 1

基于代码检测的分析器对于这种非常快的函数几乎毫无用处，您可以从中得到的任何东西都只是随机数。

原因是现代 CPU 上的执行时间是一个非常复杂的函数，包含大量参数和检测(添加到函数中以更新统计信息的代码)会把一切搞砸。对于像这样的短函数，单独的检测可能比被检测的代码本身要多得多。

为了分析快速函数，你应该使用像 OProfile 这样的被动分析器。只需运行程序并以准定期的间隔检查它所在的位置。您得不到精确的计数器，但您可以从随机抽样中获得的近似值更接近真实情况，因为程序行为并未发生太大改变。

查看程序在哪里浪费时间的另一种方法是通过试验。如果您怀疑代码的某个部分是瓶颈，那么尝试执行它 10 次(这通常不难做到)并检查程序的总执行时间变化了多少。如果减速幅度不大，那么您就会知道，即使能够完全删除该代码也不会为您节省太多。