Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Visual Studio - Parallelizing builds doesn't improve performance

I've been playing around with some large visual studio C++ projects, and it seems that more time is spent building the precompiled header than the individual source files.

I've since made some changes to the project itself (enabled the /MP flag and set the max number of jobs in "Tools ==> Options"), and the builds seem to be about 10% faster, but not nearly as great an improvement as the Linux versions of the same projects, which run nearly 4-5x faster when specifying the -j option in make.

First, are there any other options that need to be set to take advantage of multi-core systems for improving build speed, particularly with generating the precompiled header?

Second, it seems that by enabling multi-processor support, I can no longer do "incremental builds". If I understand this correctly, each "Build" would be the same as a full "Rebuild" or "Clean, Build" operation. Is this so? Last I checked, GNU makefile projects don't suffer from this limitation if the makefile is written properly, so it seems odd such a modern and expensive tool as Visual Studio would suffer from such an issue.

Thank you.

like image 768
Cloud Avatar asked Jun 04 '26 14:06

Cloud


1 Answers

I have been investigating this problem over the last week. It turns out that the underlying "msbuild" tool with parallel building enabled ("/m:njobs") can build projects in parallel, but the individual tasks within a project are always serial. Given the dependencies between projects, it often means that the amount of parallelisation opportunities are quite limited.

I use CMake to generate the solution and project files which means it's possible to compare the same build using generators for different build systems. I've been using the Ninja build tool, which can make much better use of parallelisation. Monitoring the use of all CPU cores with the resource monitor shows that MSBuild uses 1 core, sometimes 2. Ninja pegs all 8 cores to the limit for the vast majority of the build on my workstation. For my code, this translates to 125 mins with msbuild vs 45 mins with Ninja on a 24-core build node--the fact that it's not a 24x speedup is that the unit tests take up most of that time and are not parallellised, but I did see it peg all 24 cores during the build unlike msbuild.

So the general take home message is that Visual Studio/msbuild support for effective parallelisation is quite limited, and if you want to make your builds as fast as possible, you will have to look elsewhere for better tools. I found CMake/Ninja to be an effective alternative.

like image 193
Roger Leigh Avatar answered Jun 07 '26 13:06

Roger Leigh



Donate For Us

If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!