c++ - g++ 在多个文件上比使用 Google mock 的单一文件慢得多

Question

我遇到了一个似乎与 g++ 相关的问题。基本上，当一个程序被拆分成多个文件而不是一个单一的整体文件时，g++ 需要花费更多的时间来编译它。事实上，如果将单个文件组合在一起并进行编译，它运行起来比在 g++ 命令行上列出单个文件要快得多。比如9个文件，编译需要1分39秒；当我把它们放在一起时，编译只需要 13 秒。我试过使用 strace 但它只是卡在 cc1plus 中；当我使用 -f 选项时，我仍然无法找出导致问题的原因。

我已经隔离了问题。这是重现它的方法。我写了一个非常简单的程序，像这样:

void func_01(int i) 
{
  int j;
  volatile int *jp;

  jp = &j;

   for (; i; i--) ++*jp;
}

void call_01(void)
{
  func_01(10000);
}

int main(int argc, char *argv[])
{
  call_01();
}

然后我复制了它，删除了 main 并替换了递增的数字，共 999 次。然后我 build 了:

% time g++ -c test*.cpp

real    0m18.919s
user    0m10.208s
sys     0m5.595s
% cat test*.cpp > mon.cpp
% time g++ -c mon.cpp  

real    0m0.824s
user    0m0.776s
sys     0m0.040s

因为我打算扩展到数百个比这复杂得多的文件，所以缩短构建时间很重要。任何人都可以帮助解释为什么会发生这种情况，或者提供一个不那么粗暴的解决方法吗？我认为这在一定程度上与预处理器和包含守卫带来的节省有关，因为即使我包含一个文件，时间差也会大大增加(在一种情况下是五倍)但它仍然存在，没有包含，使用整体文件要快 20 倍。

g++的版本是4.4.2，我查了一下最新的版本，8.2.0，也有。

Answer 1

有两种不同的效果:

1. 编译器调用开销:编译器是复杂的可执行文件，有时它们甚至分为前端和后端可执行文件，前端为每个单独的源文件生成后端，即使所有源文件都传递给同一个编译器调用前端。例如，Gcc 和 llvm 就是这样做的。

   • 指定 g++ -v 以查看这些冗余编译器调用。这回答了你的主要问题，我想为什么即使没有头文件也会发生这种情况。

2. 由于从头开始一遍又一遍地解析和编译相同的头文件而产生的开销。在实际示例中，此 header 开销将比编译器调用本身重要得多。

because if I include even one file, the time difference is dramatically increased (a factor of five in one case)

是的!这也可能慢 1000 倍而不是 5 倍。对于模板密集型代码，编译器需要在编译时做很多事情。

拆分多个源文件时速度减慢对您造成打击，尤其是对于 C++ 代码，因为 C++ 头文件密集。您的所有源代码 *.cpp 都是单独编译的，并且它们包含的所有 header 都包含在每个单独的源文件中。

现在如果你把所有的源文件放在一起，所有的头文件，正如你所说的，因为包含保护而只被解析一次。由于编译器将大部分时间花在解析和编译 header 上，这非常重要，尤其是对于模板繁重的代码(例如，使用 STL 就足够了)。

手写 C++ 源代码和生成的 C++ 源代码的源文件数量是以下各项之间的权衡:

1. 我的完整重建时间很快，但我的增量构建时间很慢。

   • 当您只有一个源文件(即 *.cpp 文件)或很少的源文件时就是这种情况。

2. 我的完整构建时间很慢，但我的增量构建时间很快。

   • 当您有很多小源文件(即 *.cpp 文件)时就是这种情况。

(在任何情况下，头文件的数量都无关紧要(除非你总是引入太多冗余的东西。这与编译器调用的数量有关，即 *.cpp 或 *.o 文件的数量.)

对于 1. 从头开始​​的完整编译时间很短，因为编译器只看到所有头文件一次，这在 C++ 中很重要，尤其是对于基于模板的仅头文件(或头文件密集型)库，如 STL 或 boost。

对于2，单个编译时间很快，因为当数百个文件中的一个文件发生变化时，*.cpp 文件中只有很少的代码需要编译。

这在很大程度上取决于您的用例。

如果您生成 C++ 代码，您应该向生成器添加一个选项，以允许用户选择使用哪种方式进行权衡。