源代码合并真的能提高C或c++程序的性能吗?

Does source code amalgamation really increase the performances of a C or C++ program?

本文关键字：程序 c++ 性能真的合并源代码更新时间：2023-10-16

代码合并包括将整个源代码复制到一个文件中。

例如，SQLite这样做是为了减少编译时间并提高结果可执行文件的性能。在这里，它的结果是一个184K行代码的文件。

我的问题不是关于编译时间(这个问题已经回答了)，而是关于可执行文件的效率。

SQLite开发者说:

除了使SQLite更容易合并到其他项目中，合并还使它运行得更快。许多编译器能够对包含在单个翻译单元(例如合并单元)中的代码进行额外的优化。当我们使用合并来编译SQLite而不是单独的源文件时，我们已经测量到了5%到10%的性能改进。这样做的缺点是，额外的优化通常采用函数内联的形式，这往往会使生成的二值图像的大小更大。

根据我的理解，这是由于过程间优化(IPO)，编译器进行的优化。

GCC开发者也这么说(感谢@nwp提供的链接):

编译器根据它对程序的了解执行优化。一次编译多个文件到一个输出文件模式允许编译器在编译每个文件时使用从所有文件中获得的信息。

但他们并没有谈到这样做的最终结果。

除了SQLite之外，是否有任何测量可以证实或反驳以下说法:在使用gcc编译时，带有合并的IPO 比没有合并的IPO 生成的可执行文件更快?

作为一个附带问题，关于这个优化，做代码合并或将所有。cpp(或。c)文件#包含到一个文件中是一样的吗?

源代码文件的组织不会"产生更有效的二进制文件"，并且从多个源文件中检索的速度可以忽略不计。

一个版本控制系统将接收任何文件的增量，无论大小。

通常，像这样的独立组件被单独编译以产生包含相关目标代码的二进制库:源代码不会每次都重新编译。当"应用程序A"使用的"库B"被更改时，"应用程序A"必须被重新链接，但如果库的API没有更改，则不必重新编译。

并且，就库本身而言，如果它由(数百个)独立的源文件组成，则在重新链接库之前，只有已更改的文件必须重新编译。(任何Makefile都会这样做。)如果源代码是"一个巨大的东西"，那么您每次都必须重新编译所有的源代码，这可能需要很长的时间……基本上就是浪费时间。

有两种方法可以将库中的目标代码(一旦构建…)合并到可执行文件中:静态链接和动态链接。如果使用静态链接，库的必要的部分将被复制到可执行文件中…但并不是全部。运行可执行文件时，库文件不必存在。

如果使用动态链接，整个库存在于一个单独的文件中(例如: .DLL或.so)， 必须在运行时存在，但它将被同时使用它的每个应用程序共享。

我建议您首先将其视为源代码管理问题，而不是将其视为会赋予任何技术或运行时优势的东西。(它不会)我发现很难找到一个令人信服的理由来这样做。