C++代码一直以其运行时的高性能高调面对世人, 但是说起编译速度,却只有低调的份了。比如我现在工作的源代码,哪怕使用Incredibuild调动近百台机子,一个完整的build也需要四个小时,恐怖!!!虽然平时开发一般不需要在本地做完整的build,但编译几个相关的工程就够你等上好一段时间的了(老外管这个叫monkey around,相当形象)。想想若干年在一台单核2.8GHZ上工作时的场景 - 面前放本书,一点build按钮,就低头读一会书~~~往事不堪回首。
可以想象,如果不加以重视,编译速度极有可能会成为开发过程中的一个瓶颈。那么,为什么C++它就编译的这么慢呢?
我想最重要的一个原因应该是C++基本的"头文件-源文件"的编译模型:
- 每个源文件作为一个编译单元,可能会包含上百甚至上千个头文件,而在每一个编译单元,这些头文件都会被从硬盘读进来一遍,然后被解析一遍。
- 每个编译单元都会产生一个obj文件,然后所以这些obj文件会被link到一起,并且这个过程很难并行。
这里,问题在于无数头文件的重复load与解析,以及密集的磁盘操作。
下面从各个角度给出一些加快编译速度的做法,主要还是针对上面提出的这个关键问题。
一、代码角度
二、综合技巧
- 预编译头文件(PCH)
把一些常用但不常改动的头文件放在预编译头文件中。这样,至少在单个工程中你不需要在每个编译单元里一遍又一遍的load与解析同一个头文件了。
- Unity Build
Unity Build做法很简单,把所有的cpp包含到一个cpp中(all.cpp) ,然后只编译all.cpp。这样我们就只有一个编译单元,这意味着不需要重复load与解析同一个头文件了,同时因为只产生一个obj文件,在链接的时候也不需要那么密集的磁盘操作了,估计能有10x的提高,看看这个视频感受一下其做法与速度吧。
- ccache
compiler cache, 通过cache上一次编译的结果,使rebuild在保持结果相同的情况下,极大的提高速度。我们知道如果是build,系统会对比源代码与目标代码的时间来决定是否要重新编译某个文件,这个方法其实并不完全可靠(比如从svn上拿了上个版本的代码),而ccache判断的原则则是文件的内容,相对来讲要可靠的多。很可惜的是,Visual Studio现在还不支持这个功能 - 其实完全可以加一个新的命令,比如cache build,介于build与rebuild之间,这样,rebuild就可以基本不用了。
- 不要有太多的Additional Include Directories
编译器定位你include的头文件,是根据你提供的include directories进行搜索的。可以想象,如果你提供了100个包含目录,而某个头文件是在第100个目录下,定位它的过程是非常痛苦的。组织好你的包含目录,并尽量保持简洁。
三、编译资源
要提高速度,要么减少任务,要么加派人手,前面两个方面讲得都是减少任务,而事实上,在提高编译速度这块,加派人手还是有着非常重要的作用的。
另外,这本书谈了很多这方面的内容:大规模C++程序设计。
|
请发表评论