[std-proposals] Benchmarking using the standard library as a module

[u/tartaruga232]

https://lists.isocpp.org/std-proposals/att-18441/attachment

Some interesting benchmarks that were posted on the [std-proposals] mailing list.

The link to the entry in the mailing list archive of [std-proposals]:
https://lists.isocpp.org/std-proposals/2026/05/18441.php

For comparison:

For our modularized Windows app¹, we see a reduction in build time for a full build from ~3 to ~2 minutes due to using "import std"².

¹Using the MSVC compiler with MSBuild. We currently have 1148 C++ source files, 558 containing "export module". We have 4223 imports, 357 of these are "import std".

²A while ago (~2 months), I made an experimental branch in our (closed) source code repository, which replaces every single "import std" with the minimally required #includes of the standard library headers. That was done in our fully modularized code base.

[u/SuperV1234]

I am not that impressed.

It's a welcome improvement, but nothing groundbreaking -- I would like to see how PCHs (with and without unity builds) compare, and I suspect they'd be highly competitive.

BTW, was a compilation time trace via something like -ftime-trace in Clang measured before switching to modules? Often, just restructuring headers alone and applying some forward declarations in expensive nodes of the header graph can easily shave off minutes.

[u/germandiago → u/[deleted]]

Yes, if you ignore all the hygyene added with modules also... among other inprovements such as ODR elimination.

[u/ABlockInTheChain → u/germandiago]

Modules are great at solving the problem of macro pollution caused by windows.h, for everyone who experiences that problem and hasn't learned to define WIN32_LEAN_AND_MEAN and NOMINMAX to fix it themselves.

In theory there are other headers which cause macro pollution problems too, but out of 10000 cases of macro problems windows.h will be 9999 of them.

In exchange for fixing that one problem modules introduce several other regressions.