GCC构建时间不会从预编译头中获益

Evg*_*zin 15 c++ gcc build-process gnu-make precompiled-headers

我有一个庞大的项目,大约有150,000个LOC的C++代码.建设时间约为15分钟.该项目由许多不同规模的子项目组成.

我为每个子项目构建了单独的预编译头,但是当我使用它们时,构建时间保持大致相同.似乎构建时间减少了5-10%,而不是更多.

绝对使用预编译的头文件,我使用-Winvalid-pch选项,我尝试使用编译-H器选项进行编译,我的预编译头文件在输出中出现'bang'符号,​​这意味着编译器能够使用预编译头文件.

我所有预编译的头文件都不是很大,每个文件大约有50Mb.我使用python脚本,在这里生成最常用的预编译头文件列表,所以我的预编译候选列表非常好.

是否有用于构建优化的免费/开源工具?标准make实用程序似乎无法测量不同目标的构建时间.我无法找到获取不同目标统计数据的方法make.我不是在谈论依赖性分析或者先进的东西.我只是想知道大部分时间浪费在哪些目标上.

此外,GCC似乎在处理预编译头文件方面效率很低.我无法让任何子项目构建速度明显更快,我得到的最大加速比例是20%,对于一个需要三分钟构建的项目.使用固态硬盘购买速度更快的机器似乎比使用GCC优化Linux上的构建时间更容易和更便宜.

Jon*_*ely 10

GCC构建时间不会从预编译头中获益

是的,不幸的是,这通常是真的,

有一些实验项目可以做得更好,请参阅http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3426.htmlhttp://gcc.gnu.org/wiki/pph,但它们还没有用.

我同意另一个答案,150KLOC的15分钟很慢.

我发现使用Gold链接器会对构建时间产生巨大影响,我强烈推荐它.

你也可以考虑的ccache,它可以帮助,如果您有其他机器上的空闲周期的distcc

避免在慢速磁盘上构建,当然要避免使用网络磁盘.避免递归调用make,这会花费更多时间来阅读makefile并重新创建依赖图.如果您可以构建子项目makefile,以便它们都可以包含在单个顶级makefile中,那么非递归make将需要更长时间才能开始,但是一旦它开始构建目标就会飞行.但是,重写makefile可能需要做很多工作.

并且它可能不言而喻,但是建立在多核计算机上并且使用make -j N一个好的经验法则N应该是核心数量的两倍,或者如果编译是I/O绑定则更多.

  • 我试过ccache,重新编译现在非常快.我将尝试金链接器tomorow,感谢您的建议. (2认同)

jus*_*tin 6

如果您想充分利用此功能,您需要了解如何构建项目以充分利用它们.最好的方法是手动减少构建时间的缓慢而艰难的过程.一开始听起来真的很愚蠢,但是如果所有构建版本都快5倍,并且你知道如何构建你的项目和依赖关系 - 那么你就会意识到收益.

您可以使用目标设置持续集成系统,以便在您的更改进入时衡量和记录您的进度/改进.

我有一个庞大的项目,大约有150,000个LOC的C++代码.建设时间约为15分钟.该项目由许多不同规模的子项目组成.

假设你有一台现代化的机器,听起来它正在做很多冗余的工作.

还要考虑链接时间.

我所有预编译的头文件都不是很大,每个文件大约有50Mb.

这是相当大的,IMO.

我不是在谈论依赖性分析或者先进的东西.

再次,统计数据的持续集成.对于构建缓慢,过度依赖很可能是问题(除非你有许多小的cpp文件,或者像物理内存耗尽一样愚蠢).

我无法让任何子项目构建得更快,我得到的最大加速是20%

了解您的结构和依赖关系.PCH减慢了我的大多数项目.

使用固态硬盘购买速度更快的机器似乎比使用GCC优化Linux上的构建时间更容易和更便宜.

有可能,该机器不会使您的构建时间快20倍,但修复您的依赖项和项目结构可以使它快20倍(或者最终问题的根源).机器只有这么多(考虑到150KSLOC的构建时间).

您的构建可能是CPU /内存绑定.