4 ms·

I see no reason to believe this will actually be the case based on anecdotal evidence from folks I know who have tried out the early module implementations. I’m

I see no reason to believe this will actually be the case based on anecdotal evidence from folks I know who have tried out the early module implementations. I’m hoping they are wrong, but I do not think that modules or anything else is going to result in a significant speedup for the average case, and large C++ compile times will remain a perpetual feature of the language.

pjmlp 3y ago
As per Microsoft talks, C++23 import std; is faster than a plain #include <iostream>.
- bluGill 3y ago
  But clang and GCC have not reported anything (it doesn't work), but they have always been careful to not get people's hopes up
  - pjmlp 3y ago
    How could they? Their module support barely works, and will take a couple of years to catch up to VC++. Other C++ compilers are even more behind in regards to catching up to ISO C++.
    - bluGill 3y ago
      Exactly. They have been cautious about claiming if modules will actually speed up compilation when they arrive. They might be a visual studio only win for speed. (Still useful for simplicity over include files)
- jlokier 3y ago
  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.
  - pjmlp 3y ago
    Visual Studio has one of the best precompiled headers implementations. So I would take a few minutes before wondering how bad they handled #includes. Precompiled headers exist in the PC world, across all major compilers, since Windows 3.x days.
delta_p_delta_x 3y ago
Vulkan-Hpp has a module interface file[1] that just exports a bunch of `using` declarations. The speedup is significant, because the Vulkan-Hpp headers are immense: `vulkan_structs.hpp`[2] is 116000+ lines on its own. With the module, the giant list of names is compiled once into a large file, and then imported into consumers as necessary. [1]: https://github.com/KhronosGroup/Vulkan-Headers/blob/main/include/vulkan/vulkan.cppm https://github.com/KhronosGroup/Vulkan-Headers/blob/main/inc... [2]: https://github.com/KhronosGroup/Vulkan-Headers/blob/main/include/vulkan/vulkan_structs.hpp https://github.com/KhronosGroup/Vulkan-Headers/blob/main/inc...

pjmlp 3y ago

As per Microsoft talks, C++23 import std; is faster than a plain #include <iostream>.

bluGill 3y ago
But clang and GCC have not reported anything (it doesn't work), but they have always been careful to not get people's hopes up
- pjmlp 3y ago
  How could they? Their module support barely works, and will take a couple of years to catch up to VC++. Other C++ compilers are even more behind in regards to catching up to ISO C++.
  - bluGill 3y ago
    Exactly. They have been cautious about claiming if modules will actually speed up compilation when they arrive. They might be a visual studio only win for speed. (Still useful for simplicity over include files)
jlokier 3y ago
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.
- pjmlp 3y ago
  Visual Studio has one of the best precompiled headers implementations. So I would take a few minutes before wondering how bad they handled #includes. Precompiled headers exist in the PC world, across all major compilers, since Windows 3.x days.

delta_p_delta_x 3y ago

Vulkan-Hpp has a module interface file[1] that just exports a bunch of `using` declarations. The speedup is significant, because the Vulkan-Hpp headers are immense: `vulkan_structs.hpp`[2] is 116000+ lines on its own. With the module, the giant list of names is compiled once into a large file, and then imported into consumers as necessary. [1]: https://github.com/KhronosGroup/Vulkan-Headers/blob/main/include/vulkan/vulkan.cppm https://github.com/KhronosGroup/Vulkan-Headers/blob/main/inc... [2]: https://github.com/KhronosGroup/Vulkan-Headers/blob/main/include/vulkan/vulkan_structs.hpp https://github.com/KhronosGroup/Vulkan-Headers/blob/main/inc...