C++项目要怎么缩短编译时间?

忆困血馆闻 · 发表于 2021-1-7 09:54

GCC 5.x受了“刺激”从C切换到C++
Requirements - state-removal 0.1 documentationLLVM一直用C++，每次在本地编译的时候，特别是打开Debug，我就会逛知乎打发时间，就像现在这样 :) 或者公司可以上40核编译服务器 make -j40 但是我还是习惯在本地编译测试好先，再提交到编译器服务器上，以免犯低级错误逃）

风吹吹蛋蛋疼风w · 发表于 2021-1-7 09:56

给个可行的思路：
并行编译（只编译，不要链接）
并行链接（生成可执行文件）

123456790 · 发表于 2021-1-7 09:58

(1)常用的公共头文件放进预编译头
(2)采用pimpl简化头文件
(3)启用多处理器并行编译(MSVC编译器开关/MP)
(4)启用增量链接(MSVC链接器开关/INCREMENTAL)
(5)避免过长的编译单元(拆分源代码文件)

永远爱你冰塘 · 发表于 2021-1-7 10:03

首先，推荐一个有关这个主题的非常好的资料
幻灯片：《The Hitchhiker&#39;s Guide to Faster Builds》
视频：https://www.youtube.com/watch?v=WY2SluG-Dv0&feature=emb_title
作者在演讲中，总结了导致C++项目编译慢的原因，以及所有可能的解决办法。
既然编译慢可能是由不同原因导致的，那在实际中就只有对症下药了。另外，许多解决方案是侵入性的，那就是要改代码，不仅麻烦，而且风险高。
在我们最近的实践中，Jumbo/Unity Build能够极大地减少编译时间，大约缩短了2/3左右，效果显著。Unity Build指的是把多个源文件合成一个源文件再编译的方法。这种方法可以加快编译的原因是避免了多次重复解析头文件，即使这些头文件都是相同的。
Google Test项目在代码中用了头文件包含的方式来实现Unity Build。它的这种方式是需要修改代码的，因此是侵入式的。
Chromium项目中也使用了Unity Build。见 https://chromium.googlesource.com/chromium/src/+/63.0.3239.84/docs/jumbo.md 。
CMake自从3.16版本就开始支持Unity Build。详细教程见 https://onqtam.com/programming/2019-12-20-pch-unity-cmake-3-16/ 。
CMake的这种实现方式是非侵入性的，也就是几乎不需要修改代码，只需要在CMakeList中打开开关就可以了。之所以说几乎不需要修改，是因为Unity Build的实现方式会导致正常的代码编译不通过，这时就需要修改。比如，当两个文件中出现同名符号时，它们最后被放在了同一个源文件中，就会出现问题。
使用Unity Build有利有弊，但如果缩短的编译时间确实很多的话，应该还是值得的，因为大家应该都体会过等待编译是多么痛苦的一件事情。

素色流年783 · 发表于 2021-1-7 10:11

这件事情Unreal Engine4已经想到了。楼上的办法都不能彻底解决问题。。。
楼主建议看看Unreal4怎么做的。。不过估计你做不到那样

万胜 · 发表于 2021-1-7 10:14

几分钟这还烦？
刚来我们公司的时候，二三十万行的代码，加上电脑是之前离职同事的巨卡电脑。编译一下要两个多小时，而且公司的产品调试无法打断点只能看log，就在这种情况下，我竟然还坚持过去了。。。

惜颜705 · 发表于 2021-1-7 10:22

1. 少用模版
2. 依赖抽象接口，将抽象接口放在公共头文件中，实现类放在私有头文件中

462710480 · 发表于 2021-1-7 10:25

最近给公司项目重新梳理构建，规模不庞大(20w，不包括第三方库)，目前全量编译时间是10s，我们采用方法有

现在觉得还够丝滑，后续业务规模起来考虑分布式编译。
如果业务真大到一次编译喝杯咖啡，买他几台make -j128，咱不缺钱了

David902 · 发表于 2021-1-7 10:33

提一下一个小众的编译系统，tup。
它的特点是在编译前期把所有依赖和改动都扫描一遍构建DAG决定编译顺序，不用重复检查依赖项，从而节省时间。
缺点是要用特殊的语法写配置，可用lua扩展。因为小众，搜得到的可供参考的经验也少。

乌克兰同事被整体裁员前在产品中引入了这个东西，我们接手后不太适应，觉得拧巴。全新编译要比原来的makefile快了40%（官方的数据是和makefile差不多，可能是因为我们原来的makefile写的比较渣），增量编译应该优势更大。

http://gittup.org/tup/manual.html

123456848 · 发表于 2021-1-7 10:41

如果是指gcc的话，推荐用CMake来编译，比makefile语法简单，自动搞定生成.o文件和增量编译。
如果是执行一次全量编译，觉得慢的话，用make -j4，其中4是你cpu的核数，这执行的是多进程编译。
如果觉得多进程编译还太慢，可以上ssd。
上了ssd还觉得慢，少用模板。
去了模板还太慢，换电脑。或者考虑放在另一台电脑来编译。就算慢也不卡你电脑哈。

		自动登录	找回密码
密码			立即注册