C++ 项目的编译时间一般可以从以下几个角度进行优化：
- 使用 Pimpl 模式
- 移动语义替代复制语义
- 前向声明替代 include
- 优化依赖关系
- 预编译头文件技术（PCH）
- 谨慎使用 inline 和 template
- 不改代码：借助硬件性能
使用 Pimpl 模式
声明与实现分离，接口定义要相对稳定，include 时只 include 这个接口头文件就好。
Pimpl（Pointer to Implementor），顾名思义就是将真正的实现细节的 Implementor 从类定义的头文件中分离出去，公有类通过一个私有指针指向隐藏的实现类，是促进接口和实现分离的重要机制。
通常的 Pimpl 的手法是在 API 的头文件中提供接口类的定义以及实现类的前置声明，实现类的本身定义和成员函数的实现都隐藏在 cpp 文件中去，同时为了避免实现类的符号污染外部名字空间，实现类大多作为接口类的内部嵌套类的形式。
不使用 Pimpl 手法，代码会像这样：
#include <x.h>
class C {
public:
void f1();
private:
X x; // 与 X 的强耦合
};
从语义上来说，成员数据 x 是属于类 C 的实现部分，不应该暴露给用户。
从实现上来说，在用户的代码中，每一次使用 new C 和 C c1 这样的语句，都会将类 X 的大小硬编码到编译后的二进制代码段中（如果类 X 有虚函数，则还不止这些）——这是因为，对于 new C 这样的语句，其实相当于 operator new(sizeof(C)) 后面再跟上类 C 的构造函数，而 C c1 则是在当前栈上腾出 sizeof(C) 大小的空间，然后调用类 C 的构造函数。因此，每次类 X 作了改动，使用 c.h 的源文件都必须重新编译一次，因为类 X 的大小可能改变了。
而使用 Pimpl 手法的代码像这样：
#include <x.h>
class C {
...
private:
X* pimpl; // 这时 class X 不用完全定义, 因为任何指针的大小都是相同的, 这个大小已经确定了
};
当用户 new C 或者 C c1 的时候，编译器生成的代码中不会掺杂类 X 的任何信息。
移动语义替代复制语义
当一个函数的参数按值传递时，就会进行拷贝。对于基本数据类型，编译器懂得如何去拷贝。 而对于自定义的类型，我们需要提供拷贝构造函数。
但不得不说，拷贝的代价是昂贵的。所以我们需要寻找一个避免不必要拷贝的方法，即 C++11 提供的移动语义。移动语义一般是通过右值引用的方式实现的。
在 C++ 中临时变量在表达式结束后就被销毁，之后程序就无法再引用这个变量了。但 C++ 11 提供了一个方法，让我们可以引用这个临时变量。这个方法就是所谓的右值引用。
移动构造函数类似于拷贝构造函数，把类的实例对象作为参数，并创建一个新的实例对象。但是移动构造函数可以避免内存的重新分配，因为我们知道右值引用提供了一个暂时的对象，我们可以把它当做一个临时存储。这就意味着我们要移动而不是拷贝右值参数的内容。从而节省很多的时间和空间。
如下是一个移动赋值运算符语法示例：
A& operator=(A&& other) {
if (this != &other) {
// 释放已有资源
delete[] mData;
mData = other.mData;
// 释放源对象指针
other.mData = NULL;
}
return *this;
}
前向声明替代 include
删除不必要的 include，使用前向声明（forward declaration）替代。
C++ 的类可以进行前向声明。但是，仅仅进行前向声明而没有定义的类是不完整的，这样的类，只能用于定义指针、引用，以及用于函数形参的指针和引用。不能用于定义对象（因为此时编译器只知道这是个类，还不知道这个类的大小有多大），也不能访问类的对象。
如 Pimpl 模式一节的例子可以将 #include <x.h> 替换为前向声明：
class X; // 前向声明, 类 X 的定义在 x.h 文件中
class C {
...
private:
X* pimpl; // 这时 class X 不用完全定义, 因为任何指针的大小都是相同的, 这个大小已经确定了
};
优化依赖关系
- 避免循环 include，通常如果出现这种现象，应该重新组织文件布局，使得项目高度模块化。
- 使用条件编译语句可以避免重复 include，但绝大多数 C++ 编译器在遇到这个语句时仍会把"打开文件并读取文件内容然后进行字符串扫描"这套动作做一遍。出于这个角度，我们也应该主动优化依赖关系，减少编译过程中所需的 I/O 量。
预编译头文件（PCH）技术
要使用预编译头，我们必须指定一个头文件，这个头文件包含我们不会经常改变的代码和其他的头文件，用一个 .cpp 包含它并编译生成一个 .pch 文件（GCC 下直接 g++ x.h 即可，生成的预编译头后缀为 .gch，不同后缀的预编译头不兼容），在接下来编译到 include 这个头文件的代码时，就直接使用预编译头文件了，速度的提升相当明显。
这些预先编译好的代码可以是任何的 C/C++ 代码，甚至是 inline 函数，但是必须是稳定的，在工程开发的过程中不会被经常改变。如果这些代码被修改，则需要重新编译生成预编译头文件。
【注意】使用预编译头技术造成了一个问题：
由于它假定预编译头中包含过的头文件会在所有 .cpp 中使用，因此它在编译你的 .cpp 的时候，就会将预编译头中已经编译完的部分加载到内存中。如果它突然发现你的 .cpp 居然没有包含预编译头，整个编译过程就会失败，因为它不知道该如何将已编译完的部分从内存中请出去。
因此，如果你使用了预编译头技术，就必须在所有的 .cpp 中包含预编译头。stdafx.h 是 MFC 工程提供的一个默认的预编译头。
谨慎使用 inline 和 template
在头文件中 使用 inline 和 template 的话会强制我们包含实现，从而了增加头文件的内容，减慢编译速度。使用之前，权衡一下。
避免 inline 复杂函数，不过其实即使你声明了 inline，编译器也是自己看着来，所以一般不需特别注意。
根据标准，template 是不经过预编译，直接从源文件导入，在工程编译的时候编译的。比如所有接受数据类型名为参数的 template，几乎必须是在编译的时候才能确定到底是什么，然后直接展开到源代码里面去。举个例子，写个简单的max函数：
template <typename tname>
tname max(tname a, tname b){
return a > b? a: b;
}
如果这个 max 函数用在了 double 和 int 两种类型上，那么实际上就会编译出两个 max 函数。而整个 STL 就是一大堆模板混来混去，你用一个 vector，就至少带了一个 less 方法，即使你用不到。
不改代码：借助硬件性能
- Visual studio 和 make 都支持并行编译；
- 使用分布式编译工具，如 IncrediBuild；
- 用固态硬盘；
- 添加编译缓存 ccache。
