与使用 Google 模拟的单一文件相比，g++ 在多个文件上要慢得多

Question

我遇到了一个似乎与 g++ 相关的问题。基本上，当一个程序被分割成多个文件时，g++ 需要更多的时间来编译它而不是一个单一的整体文件。事实上，如果你将单个文件放在一起并编译，它的运行速度比在 g++ 命令行上列出单个文件要快得多。例如，有九个文件，编译需要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();
}

然后我复制了它，删除了主要的并用递增的数字代替了 999 次。然后我建立了：

% 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. 由于从头开始一遍又一遍地解析和编译相同的头文件造成的开销。在实际示例中，此标头开销将比编译器调用本身重要得多。

因为即使我包含一个文件，时差也会大大增加（在一种情况下是五倍）

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

拆分多个源文件时速度变慢，尤其是对于 C++ 代码，因为 C++ 是头文件密集型的。您的所有源代码*.cpp都是单独编译的，并且它们包含的所有头文件都为每个单独的源文件冗余包含在内。

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

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

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

   • 当您只有一个源文件（即 *.cpp 文件）或很少的源文件时，就会出现这种情况。

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

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

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

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

对于 2. 单个编译时间很快，因为当仅更改数百个文件中的一个时，只需要编译 *.cpp 文件中的极少数代码。

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

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