c++ - Visual Studio - 并行化构建不会提高性能

Question

我一直在玩一些大型的 visual studio C++ 项目，似乎花在构建预编译头文件上的时间多于单独的源文件。

我已经对项目本身做了一些更改(启用 /MP 标志并在“工具 ==> 选项”中设置最大作业数)，并且构建似乎是大约快 10%，但没有相同项目的 Linux 版本那么大的改进，在 make 中指定 -j 选项时运行速度快近 4-5 倍.

首先，是否需要设置任何其他选项以利用多核系统来提高构建速度，尤其是生成预编译头时？

其次，似乎通过启用多处理器支持，我不能再进行“增量构建”了。如果我理解正确，每个“构建”将与完整的“重建”或“清理、构建”操作相同。是这样吗？最后我检查了一下，如果 makefile 编写得当，GNU makefile 项目就不会受到这个限制，所以像 Visual Studio 这样现代且昂贵的工具会遇到这样的问题似乎很奇怪。

谢谢。

Answer 1

上周我一直在调查这个问题。事实证明，启用并行构建的底层“msbuild”工具(“/m:njobs”)可以并行构建项目，但项目中的各个任务始终是串行的。考虑到项目之间的依赖性，这通常意味着并行化机会的数量非常有限。

我使用 CMake 生成解决方案和项目文件，这意味着可以比较使用不同构建系统的生成器的相同构建。我一直在使用 Ninja 构建工具，它可以更好地利用并行化。使用资源监视器监视所有 CPU 内核的使用情况表明，MSBuild 使用 1 个内核，有时使用 2 个内核。Ninja 将所有 8 个内核都限制在我工作站上绝大多数构建的极限。对于我的代码，这相当于在 24 核构建节点上使用 msbuild 花费 125 分钟，而使用 Ninja 花费 45 分钟——它不是 24 倍加速的事实是单元测试占用了大部分时间并且没有并行化，但是与 msbuild 不同，我确实看到它在构建过程中固定了所有 24 个内核。

因此，一般带回家的信息是 Visual Studio/msbuild 对有效并行化的支持非常有限，如果您想尽可能快地构建，您将不得不在别处寻找更好的工具。我发现 CMake/Ninja 是一个有效的替代方案。