并行数量太多了也不好

　　一般来说，利用完所有处理器或处理器核心就已经足够了，否则可能会导致机器变慢甚至崩溃，下图就显示了这样一个例子。

　　图15  太多的并行构建进程很容易让机器崩溃

　　我是在一台8 CPU的机器上做的这个实验，我把解决方案中的所有项目全部开启/MP了，然后使用msbuild.exe /m进行构建(我使用命令行进行构建不会出现这个问题，但在Visual Studio中进行构建就会出现)，如果相关依赖不能阻止它，MSBuild将立即启动8个项目，每个CL将会一次运行自己的8个实例，因此总共会有64个CL运行考验我们的处理器核心和磁盘，这样做不但不能提升速度，反倒会使性能急剧下降。

　　你可能希望有一天系统能够实现自我调整，但如果现在遇到这样的问题，你不得不手工调整。下面是一些建议：

　　◆将全局值设小一点

　　例如将/m:4减少到/m:3，或使用属性表将/MP修改为/MP2，如果你的构建中还有其它问题，如有许多的并行项目，但并行的CL不够，反之亦然，这个时候你都应该将全局并行构建参数调小。

　　◆为每个项目和配置调整/MP

　　有些时候使用/MP可能不是非常好的的办法，你也可以通过配置进行调整，Retail配置可能会使速度变得更慢，因为编译器要做的优化更多了，为Retail开启/MP而不是为Debug开启/MP可能更有意义。

　　◆获得超级定制

　　在你的团队中，你可能有一系列硬件，也许你的开发人员使用的是双CPU机器，但夜间构建是在一台8 CPU的机器上进行的，两者构建时需要的来源是一样的，你希望两者的速度都不能太慢，在这种情况下，你可以使用环境变量，或是在MSBuild标签上设置条件，几乎所有MSBuild标签都可以设置条件。

　　下面是一个例子，当“MultiprocCLCount”有一个大于零的值时，就可以使用这个值启用/MP。

　　图16  通过环境变量调整处理器数量

　　MSBuild启动时将所有环境变量的值作为初始属性值，因此在我更快速的机器上，我将MultiprocCLCount的值设为8，而在我的开发用机上，我将其设为2。

　　类似的方法还可以应用到MSBuild.exe的/m参数中，如/m:%MultiprocMSBuildCount%，

　　在外来条件中还有其它属性可能很有用，如$(Number_Of_Processors)表示逻辑处理核心数量，它来自环境变量。$(MSBuildNodeCount)是传递给msbuild.exe /m参数的值，在Visual Studio中，这个值是通过“工具”*“选项”进行设置的。

　　最后，我希望你能有效利用/m和/MP。希望你对我介绍的MSBuild功能能进一步深入学习，最好自己动手配置一次。