On 22 May 2026 12:59, Marcin Jaczewski wrote:
> pt., 22 maj 2026 o 11:44 Andrey Semashev via Std-Proposals
> <std-proposals_at_[hidden]> napisał(a):
>>
>> On 22 May 2026 11:12, Jens Maurer via Std-Proposals wrote:
>>>
>>> On 5/22/26 03:14, Adrian Johnston via Std-Proposals wrote:
>>>>
>>>>>> But reorganizing headers at all seems kind of backwards when we have modules.
>>>>
>>>> The reality is that our current compilers still need to take the time to update their internal symbol tables with the entire contents of the module, so writing *import std;* might just kill the compile time of a large project across hundreds of files. It would make more sense to import only the standard library submodules needed as that might be faster. So we still have the problem, it is just less bad in some cases now.
>>>>
>>>> I spent a lot of time refactoring my codebase to work as a module after the response on this list and it loads slower than the textual inclusion of select headers. So I'm kind of burnt out on the topic after that, but I can do more benchmarking if anyone would like me to.
>>>
>>> The sales story for modules is that "import std" is fast.
>>> Can you share some benchmark figures for the build time of
>>>
>>> import std;
>>>
>>> int main() {}
>>>
>>> Make sure to read your compiler's documentation on modules;
>>> it is likely that you need a once-only pre-generation step
>>> to actually build the "std" module. That shouldn't factor
>>> into the benchmark timings.
>>
>> Why shouldn't it? It's going to be built every time on CI.
>
> But only once, if you have 100 TU then only 1 time it will be compiled.
> Only drawback is all this TU will need to wait for `std` module.
> This can make one build be longer but you could run two diffrent
> builds in parallel
> and they will use less resources than the old build using headers.

You will have to build the entirety of std module, even if you're not
using much of it. And you won't be relieved from including headers
anyway since not all of the world is on modules, neither it will ever be
(at the very least, C libraries won't, and there are lots of C APIs used
in C++ projects). The way I see it, in a realistic project, building std
module is an added expense to the current build times with included
headers, give or take.

However, my point was that, regardless of the supposed wins or losses
caused by modules, building std module is a cost that will be paid, and
therefore it should be included in benchmarks.

> And most importantly, the `std` module can be cached as long as you do
> not change flags
> that affect ABI the `std` module will be binary compatible.

Cached or incremental builds in CI are typically problematic, because of
the added caching infrastructure and because such builds are far too
fragile. Every time I tried it and every project that I worked with that
tried that eventually dropped the idea and opted for full rebuilds.