GCC/Make构建时优化

您可以从两个方面解决这个问题:重构代码以降低编译器看到的复杂性,或者加快编译器的执行。

无需接触代码,您就可以向其中添加更多的编译功能。使用ccache避免重新编译已编译的文件,并使用distcc在更多计算机之间分配构建时间。如果在本地编译,则使用make-j,其中N是核心数+1,对于分布式构建,则使用更大的数字。该标志将并行运行多个编译器。

重构代码。更喜欢向前声明而不是包含(简单)。尽可能地解耦以避免依赖关系(使用PIMPL习惯用法)。

模板实例化成本很高,在使用它们的每个编译单元中都会重新编译它们。如果你可以重构你的模板作为转发声明它们,然后只在一个编译单元中实例化它们。

我能想到的最好的 make 是 -j 制作

make -j

如果要将并发作业的数量限制为 N 您可以使用:

make-j N

确保依赖项正确,以便 不运行作业,不必运行。

另一件需要考虑的事情是优化 gcc 这和 -O 转换您可以指定各种级别的优化。优化程度越高,编译和链接时间越长。与我一起工作的项目需要运行2分钟来链接 -O3 ,还有半分钟 -O1 . 你应该确保你的优化没有超出你需要的范围。您可以在不优化开发构建和优化部署构建的情况下进行构建。

使用调试信息编译( gcc -g )可能会增加可执行文件的大小,并可能影响构建时间。如果你不需要它,试着移除它,看看它是否会影响你。

链接的类型(静态与动态)应该有所不同。据我所知,静态链接需要更长的时间(尽管我在这里可能是错的)。您应该看看这是否会影响您的构建。

从项目的描述来看,我猜每个目录都有一个Makefile,并且经常使用递归make。在这种情况下,技术来自 "Recursive Make Considered Harmful"

如果您有多台计算机可用,gcc由 distcc

你也可以使用 ccache 此外

所有这些都只需对makefile进行很少的更改。

这也将有助于避免不必要的重新编译,此外,对于每个源代码目录或模块,您可以有一个带有对象文件的静态库,基本上允许编译器尽可能多地重用以前编译的代码。

还有一点在前面的回答中没有提到,那就是尽可能地将符号链接设置为“私有”,即如果代码不必在外部可见,则更喜欢静态链接(函数、变量)。

此外,您可能还需要考虑使用 GNU gold linker ,即 much more efficient 用于编译ELF目标的C++代码。

基本上,我建议您仔细分析您的构建过程,并检查在哪里花费的时间最多,这将为您提供一些关于如何优化构建过程或项目源代码结构的提示。

Decider('MD5-timestamp') 对于您的SConstruct文件,SCons将首先查看文件的时间戳,如果它比以前构建的时间戳新,它将使用文件的MD5来确保您确实更改了某些内容。这不仅适用于源文件,也适用于对象文件。这意味着,例如,如果更改注释,则不必重新链接。

头文件的自动扫描也确保了我永远不必键入scons——clean。它总是做正确的事情。

如果您有一个带有开发人员机器的局域网,也许您应该尝试实现一个分布式编译器解决方案,例如 distcc .

http://ccache.samba.org/ 大大加快了速度。

我在一个中等规模的项目上工作,这是我们为加快编译速度所做的唯一一件事。

distcc 分布式编译器,以减少构建时间,如果您可以访问多台计算机。 以下是来自IBM developerWorks的一篇与distcc相关的文章,以及如何使用它: http://www.ibm.com/developerworks/linux/library/l-distcc.html

另一种减少构建时间的方法是使用预编译头。这里有一个 starting point for gcc .

另外,如果您的机器有多个cpu/核心(2倍的核心/cpu数量就可以了),那么在构建make时也不要忘记使用-j。

使用小文件可能并不总是一个好的建议。磁盘的最小扇区大小为32或64K,文件至少占用一个扇区。因此,3K大小的1024个文件(内部代码很小)实际上需要32或64兆的磁盘容量,而不是预期的3兆。驱动器需要读取的32/64兆欧。如果文件分散在磁盘上,则读取时间会随着寻道时间的增加而增加。显然,这在一定程度上有助于磁盘缓存。预编译的头文件也有助于缓解这种情况。