Date: Wed, 27 May 2026 10:16:23 -0400
On Tue, May 26, 2026 at 5:20 PM Adrian Johnston via Std-Proposals <
std-proposals_at_[hidden]> 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
std-proposals_at_[hidden]> 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
Received on 2026-05-27 14:16:35