众所周知，C++项目的编译时间一般都很就，稍微大一点的项目完全编译可能就需要几十分钟，有的可能需要好几个小时甚至更久。这对于现在的开发人员来说是非常难以忍受的一件事情！所以就有人开发了一种叫做分布式编译的东西，这个东西的思想其实很简单，就是把一个项目中的没有依赖关系的工程分给不同的机器进行同时编译，编译完以后把编译出来的结果传回来。这样的话理论上来说，如果网络内可用的空闲机器数量足够，编译时间可以缩短到一个很短的范围内。但是不排除网络通信上的影响因素。
当前分布式编译的软件有很多，比如说Xoreax的IncrediBuild，这个特点是能够与Visual Studio很好的兼容；开源的DistCC可以提供在Linux操作系统下的分布式编译，其他还有很多的分布式编译软件都可以进行分布式编译，它们各自有各自的优缺点。
今天我要介绍的主要是如何在本地提高编译的效率。我们大多数人都不可能像公司一样拥有很多数量的机器给我们用来编译，我们也不需要这么多机器。随着现在CPU的内核数量逐渐增多，我们应该充分利用这个资源来帮助我们提高编译效率。我们一般在使用Visual Studio去Build的时候它会起一个MSBuild的进程来对我们的项目进行编译，很明显这不能发挥我们多核的优势。
做了一个小实验来验证一下MSBuild的”平行编译”的效率，Test.sln有4个Project，每个Project有一个main函数，包含1000行”Hello world”。系统配置双核2.1GHz。
直接Build (命令: MSBuild test.sln), 用时: 14.75 s
调用 两个进程Build (命令: MSBuild /m:2 test.sln), 用时: 9.85 s
调用 三个进程Build (命令: MSBuild /m:3 test.sln), 用时: 11.06 s
调用 四个进程Build (命令: MSBuild /m:4 test.sln), 用时: 10.09 s
< xmlnamespace prefix ="o" ns ="urn:schemas-microsoft-com:office:office" />
从以上的实验我们可以得出结论，并非分配的进程越多越好，因为计算机本身CPU的内核书限制，对于这个实验来说如果分配两个进程，那么正好可以被分配到两个CPU中这样就可以很大程度上的提高编程效率。但是当多余2个进程时，就并非真正的并发编译，所以效率也不会提高很多。
一个MSBuild进程会去编译一个Project，如果你需要编译的项目中只有一个Project的话，那么这个并不会提高你的编译速度。
另外，如果说这个项目中各个工程之间有依赖关系的话，效率提高也就没那么的高，因为在有依赖关系的工程必须顺序编译而不能并行编译。
此外对于为何MSBuild会起多个进程去编译而非创建线程去编译，是因为一个进程只能访问当前目录，不管你有多少个线程。
关于在多核环境下MSBuild的并行编译可以去阅读这篇文章：Faster Builds with MSBuild using Parallel Builds and Multicore CPUs，其中有详细的说明。