zapcc VS stl-header-heft

C++ modules helps with the parsing problem similar to precompiled headers, but it doesn't help with the code execution at compile time problem. All your overload matching, free function lookup, SFINAE, concept matching, and consteval code needs executing and that can take very considerable time. Other than JITing all that stuff, and maybe running an in-memory server like https://github.com/yrnkrn/zapcc, I don't know what more can be done here.

If you use clang, that might be of interest: https://github.com/yrnkrn/zapcc

The older I get the more I think #include in public headers needs to have a whitelisted regex git push filter, and the permitted whitelist of permitted includes is small and excludes most of the standard library. https://github.com/ned14/stl-header-heft, after all.

As you know, every two years or so I update https://github.com/ned14/stl-header-heft and historically the only STL to shrink in terms of token count has been yours, albeit starting from a high initial base. libstdc++ consistently grows. I look forward to discovering how VS2022's STL compares to preceding editions.

You may want to have a look at https://github.com/ned14/stl-header-heft too :)

string_view drags in a ton of the STL. string_view cannot deallocate on destruction. See https://github.com/ned14/stl-header-heft.

Even million line C++ codebases can compile from scratch within minutes if your header files never include anything not in the least impact headers list from https://github.com/ned14/stl-header-heft.