On Tue, May 26, 2026 at 5:20 PM Adrian Johnston via Std-Proposals <std-proposals@lists.isocpp.org> wrote:

Simply calling fork() in the compiler was my favorite response so far. If the world moves towards import std; everywhere I think the case for that becomes compelling.

Again, my original point on this mailing list was just that there is a cost to adding more and more to the same headers with every version of the standard. I provided this benchmarking data because I was asked and I am also interested in experimenting with the latest C++ features.

I still feel strongly about having instantaneous build times, but not everyone has to agree. Just for comparison my non-allocating stripped down version of the standard loads as a module and creates a simple object output in 16ms instead of 50ms. And that module has twice as much functionality as I would ever use.

One of the problems with a granular approach is trying to figure out what specific grains are needed and which are not. For example, you have this "non-allocating" standard library. Well, what does that even *mean*? Is that just a specific set of headers that don't happen to include any allocation functionality, or have you removed stuff from *within* headers to accomplish that? And then, which stuff? Do different compilers provide different performance based on which stuff is available?

Compiler performance is kind of a moving target across multiple platforms. Finding some set of functionality that performs better on every platform, under all compilation options, is going to be quite a task. And as new functionality is onboarded, those answers will change.

And on top of that, different people have different needs, and if "instantaneous build times" is the goal, you'll need to accommodate all of those needs. For example, "non-allocating" is not acceptable for a lot of needs. But that doesn't mean that they too couldn't benefit from a different subsection of the standard.

`import std;` is such a monumental leap forward in compile times that we're just not going to get that again. We got over a 10x improvement in standard library usage; we're not likely to get that again by performing surgery on the standard library