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

Question

我一直在研究一些大型 Visual Studio C++ 项目，似乎构建预编译头的时间比构建单个源文件的时间要多。

此后，我对项目本身进行了一些更改（启用该/MP标志并在“工具 ==> 选项”中设置最大作业数），构建速度似乎快了 10% 左右，但改进却没有那么大与相同项目的 Linux 版本一样，-j在make.

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

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

谢谢。

Answer 1

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

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

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