MSVC C++ Modules Build Benchmark: Auto-Modularizing a Real VS Solution

A developer wrote a Python script to automatically modularize a real Visual Studio solution — an undisclosed game engine — to test how well C++20 modules perform under MSVC without hand-rewriting the codebase. Header-based, MSVC-partition, and full-submodule strategies were benchmarked per-project on a 12600 CPU under debug builds, with multiple runs averaged and outliers dropped.

The headline finding: modularizing everything is not optimal. Best build-time speedups came from a middle ground — wrapping external libraries (Boost, PhysX, ImGui, spdlog, std, etc.) and the common/shared library as modules while leaving the rest of the codebase header-based. Full modularization sometimes performed no better, or worse, than header-based builds with precompiled headers. MSVC partitions consistently underperformed standalone modules, likely due to the extra dependency node they add to the build DAG.

Detailed timing breakdowns show that .cpp compilation itself gets dramatically faster with modules (up to ~4x in some cases), but that gain is largely eaten by .ixx dependency scanning and compilation overhead (SetModuleDependencies, MultiToolTask). MSBuild also appears to wait for all interface units to finish before starting any .cpp compilation, leaving parallelism on the table. On top of that, IntelliSense proved noticeably more fragile with modules than headers — a single syntax error can cascade into broad false-positive squiggles across the project.

For teams evaluating C++20 modules on MSVC, the takeaway is that selective adoption — externals plus a common core — currently yields more predictable wins than an all-in migration, while tooling around module scanning still has clear room to mature.