2016 年的时候，华为固网某个部门，编译一个有 500w 行源码的工程要 3 个多小时。后来，有个员工重写了大量 makefile 文件，改成分布式编译，编译时间缩短到 30 分钟。

部门给了 A 绩效。公司给了金牌个人。

组里面有个曾经和他一起共事的同事说，要是没有优化编译时间这回事，他合同到期应该不会续签，在此之前连 B+都很少拿。

没想到随手一答，居然那么多同行围观。再补充一点细节。

编译优化这事对于效率提升是巨大的。但风险也是极高的，很多人诟病编译太慢，但都不敢去优化。在华为干这个事，要抱着破釜沉舟的心态去搞。就像上面说的那个人，反正大概率也不续签了，搞出问题离职就行。

按照华为开发的要求，只要被代码修改影响的在研产品都需要有严格的验证。比如，库上代码被代码分析工具扫描出来指针delete后没有赋值nullptr。你在后面加上一句 ptr = nullptr。那么工作量就来了，所有使用了这个函数的在研项目你都得验证有没有问题。

回到编译优化问题，在华为搞这事的影响非常大，搞成功后的结果可能会很微小（就像评论区说的，公司没有任何奖励）。但是工作量非常大，验证的产品非常多。好在，成果是好的，把时间缩短到了原来的六分之一。

再补充一个小故事。

那时候我还是一个萌新，编译时间还是要3个多小时。某天下午5点的时候，主管发消息给我。

主管：晚上加个班，版本验证了再走。

我：好的。

等到了晚上8点30。

我：x哥，版本什么时候可以用？

主管：再等等，刚才有个傻逼紧急合入，重新跑构建了。

我：好的。

等到了晚上10点30。

我：x哥，版本出来了没有？

主管：再等等，编译出错，代码回退了，正在跑构建。

等到晚上12点。

我：x哥，版本可以用了吧？

主管：再等等，今晚上一定有版本可以用。

等到凌晨1点20。

主管：邦彦，你早点回去休息吧，版本出不来了。

我。。。。。。

会的。大型项目编译几小时也不少见。

如果几小时能缩短的10~20分钟。开发体验会得到大幅度改善。

中项目，如果10~20分钟能缩短到1~2分钟，开发体验也会得到大幅度改善。

小项目，如果5分钟能缩短到30秒以内，开发体验也会得到大幅度改善。

我们的项目以前要编译1~2小时，现在基本给优化到几分钟了。整体体验很好。

其实对于这个，我个人的推荐是：C++程序尽量规划为多进程架构，不要将整个项目放进一个可执行文件，哪怕作为动态库也不太行。因为大型项目有相当多的时间会耗费在链接这个环节。

而链接这个环节，无法用ccache加速，无法并行，无法分布式编译。。。可以说是几乎没有任何手段缩短。

那么我们怎么做呢？把大项目分成20个小项目。分成几十个独立的可执行文件。独立的可执行文件之间用进程间通讯。有效的提升了模块化以及降低了耦合，分工与调试都变得更简单清晰。而且更重要的，大幅度提升了编译速度（其实是提升了链接速度）。

我猜，随着文件尺寸的增长，链接时间，大约是指数级别增长吧。

啊哈哈~

你可以尝试着编译一下 Chrome，相信你会对这个问题有全新的认识~

而 Chrome 也只是桌面端的中大型项目，一些巨型企业级服务软件的编译时间会更长，如果一些关键步骤搞错了，还得重新来过哟~

突然能理解隔壁rust的`cargo check`了，用于检查是否可以编译。

有效减少编译错误浪费编译时间的焦虑。