On 5/22/26 11:44, Andrey Semashev via Std-Proposals wrote:
> 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.

Well, you could bake the "import std" preparations into the
preparation of the image used for CI builds, and then it's
essentially free.

So, the comparison becomes (at worst, per CI run):

 - build std module once
 - build your source files with "import std"

vs.

 - build your source files with "#include <stdwhatever>"

Benchmark figures are welcome for these two scenarios; please
also share the individual timing for "build std module once".

Jens