On Tue, Oct 12, 2021 at 2:07 AM Thiago Macieira via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> I'm not against the idea, and I'd have preferred the calendar & time and
> date
> functionality had ended up in a different header, but your timing is
> suspicious for <chrono>.
>
> It was timed on a real codebase not toy examples. I did not benchmark per
TU overhead, but when file is used 100 or 1000 times even tiny deltas add
up.
I made the measurement on system that was not doing anything else and had
not turbo enabled so timings were repeatable(20-30 sec oscilations for 25m
build) And removing chrono from common header reduced build times by around
10%.
Also it was a VS solution, it is possible that MSVC implementation of
chrono is heavier or they organize their header usage differently, for
example I noticed I get a stringstream with chrono in VS.
https://www.godbolt.org/z/nb73sxr35
So if you want to benchmark it on something like a large codebase I suggest
you add it to few widely used headers and try to benchmark then. Just make
sure gcc/clang version(more precisely their std lib) you use implements a
lot of C++20 stuff since my intuition is that new stuff is quite heavy.
Now again you could say: just dont be stupid, dont put heavy headers in
often used headers, but like I said problem is that chrono is not really
granular, so for example if I want to have something as trivial as nanos in
my header file I must include entire chrono header.

tl;dr not saying your benchmarks are wrong, but for my usecase/my compiler
<chrono> is quite heavy.