I think that says more about Microsoft's poor optimisation of #include <iostream> semantic caching.
There's no good, fundamental reason why #include caching can't be done with similar mechanisms to import, resulting in similar perfornance.
Certainly, modules are cleaner than headers. That's a language improvement and a fine reason to switch to them. Headers leak more definitions, macros etc that are part of the implementation, and their interpretation is affected by definitions before the header is included.
But in normal situations those header semantic leaks need only add a very small or negligible time overhead to symbol resolution compared with modules, both from a compiler-friendly precompiled form. Articles I've see explaining why modules are faster tend to talk about parsing headers, repeatedly, and if not parse then still process a precompiled syntax in some complicated way, as opposed to modules storing a compiler-friendly data structure. But those are merely describing how things are already done, not what's possible.
There's no good, fundamental reason why #include caching can't be done with similar mechanisms to import, resulting in similar perfornance.
Certainly, modules are cleaner than headers. That's a language improvement and a fine reason to switch to them. Headers leak more definitions, macros etc that are part of the implementation, and their interpretation is affected by definitions before the header is included.
But in normal situations those header semantic leaks need only add a very small or negligible time overhead to symbol resolution compared with modules, both from a compiler-friendly precompiled form. Articles I've see explaining why modules are faster tend to talk about parsing headers, repeatedly, and if not parse then still process a precompiled syntax in some complicated way, as opposed to modules storing a compiler-friendly data structure. But those are merely describing how things are already done, not what's possible.