Date: Thu, 21 May 2026 18:14:22 -0700
>> 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.
I am not really suggesting breaking up headers at this point. Although it
is pretty mind blowing what GCC pulls in when you include <math.h> in C++
on its own.
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.
I am not really suggesting breaking up headers at this point. Although it
is pretty mind blowing what GCC pulls in when you include <math.h> in C++
on its own.
Received on 2026-05-22 01:14:36
