洛阳电脑学校：如何加快C语言代码的编译速度

1.每个源文件作为一个编译单元，可能会包含上百甚至上千个头文件，而在每一个编译单元，这些头文件都会被从硬盘读进来一遍，然后被解析一遍。

2.每个编译单元都会产生一个obj文件，然后所以这些obj文件会被link到一起，并且这个过程很难并行。

这里，问题在于无数头文件的重复load与解析，以及密集的磁盘操作。

1、在头文件中使用前置声明，而不是直接包含头文件。

不要以为你只是多加了一个头文件，由于头文件的“被包含”特性，这种效果可能会被无限放大。所以，要尽一切可能使头文件精简。很多时候前置申明某个namespace中的类会比较痛苦，而直接include会方便很多，千万要抵制住这种诱惑;类的成员，函数参数等也尽量用引用，指针，为前置声明创造条件。

2、使用pimpl模式

pimpl全称为private implementation.传统的c 的类的接口与实现是混淆在一起的，而pimpl这种做法使得类的接口与实现得以完全分离。如此，只要类的公共接口保持不变，对类实现的修改始终只需编译该cpp;同时，该类提供给外界的头文件也会精简许多。

3、高度模块化

模块化就是低耦合，就是尽可能的减少相互依赖。这里其实有两个层面的意思。一是文件与文件之间，一个头文件的变化，尽量不要引起其他文件的重新编译;二是工程与工程之间，对一个工程的修改，尽量不要引起太多其他工程的编译。这就要求头文件，或者工程的内容一定要单一，不要什么东西都往里面塞，从而引起不必要的依赖。这也可以说是内聚性吧。

以头文件为例，不要把两个不相关的类，或者没什么联系的宏定义放到一个头文件里。内容要尽量单一，从而不会使包含他们的文件包含了不需要的内容。记得我们曾经做过这么一个事，把代码中最“hot”的那些头文件找出来，然后分成多个独立的小文件，效果相当可观。

其实我们去年做过的refactoring,把众多dll分离成ui与core两个部分，也是有着相同的效果的- 提高开发效率。

4、删除冗余的头文件

一些代码经过上十年的开发与维护，经手的人无数，很有可能出现包含了没用的头文件，或重复包含的现象，去掉这些冗余的include是相当必要的。当然，这主要是针对cpp的，因为对于一个头文件，其中的某个include是否冗余很难界定，得看是否在最终的编译单元中用到了，而这样又可能出现在一个编译单元用到了，而在另外一个编译单元中没用到的情况。

之前曾写过一个perl脚本用来自动去除这些冗余的头文件，在某个工程中竟然去掉多达了5000多个的include.

5、特别注意inline和template

这是c 中两种比较“先进”的机制，但是它们却又强制我们在头文件中包含实现，这对增加头文件的内容，从而减慢编译速度有着很大的贡献。使用之前，权衡一下。

1、预编译头文件(pch)

把一些常用但不常改动的头文件放在预编译头文件中。这样，至少在单个工程中你不需要在每个编译单元里一遍又一遍的load与解析同一个头文件了。

2、unity build

unity build做法很简单，把所有的cpp包含到一个cpp中(all.cpp) ,然后只编译all.cpp.这样我们就只有一个编译单元，这意味着不需要重复load与解析同一个头文件了，同时因为只产生一个obj文件，在链接的时候也不需要那么密集的磁盘操作了，估计能有10x的提高，看看这个视频感受一下其做法与速度吧。

3、ccache

compiler cache, 通过cache上一次编译的结果，使rebuild在保持结果相同的情况下，极大的提高速度。我们知道如果是build,系统会对比源代码与目标代码的时间来决定是否要重新编译某个文件，这个方法其实并不完全可靠(比如从svn上拿了上个版本的代码)，而ccache判断的原则则是文件的内容，相对来讲要可靠的多。

很可惜的是，visual studio现在还不支持这个功能- 其实完全可以加一个新的命令，比如cache build,介于build与rebuild之间，这样，rebuild就可以基本不用了。

4、不要有太多的additional include directories

编译器定位你include的头文件，是根据你提供的include directories进行搜索的。可以想象，如果你提供了100个包含目录，而某个头文件是在第100个目录下，定位它的过程是非常痛苦的。组织好你的包含目录，并尽量保持简洁。

要提高速度，要么减少任务，要么加派人手，前面两个方面讲得都是减少任务，而事实上，在提高编译速度这块，加派人手还是有着非常重要的作用的。