On Monday, 11 October 2021 16:35:10 PDT Ivan Matek via Std-Proposals wrote:
> Hi,
> recently I noticed that removing accidentally included <chrono> in common
> header reduced compile time by 10%. I know about tools like IWYU, but
> a) they dont always work
> b) in cases when I need something simple from a header(e.g. chrono
> nanoseconds or unique_ptr I have to include entire chrono/memory)
>
> Are there any proposals that might make this easier to manage?

Not that I've seen.

> Either more granular headers like <smart_ptr> <chrono_types> or something
> with fwd declarations maybe(although not sure if that would help with
> template heavy code like std:: implementations)
>
> P.S. this is nothing against chrono, it's C++20 additions are amazing, but
> they just seem to kill compile times.

Really? 34 milliseconds per TU is going to kill your compile time?

 Performance counter stats for '/usr/bin/g++ -S -o /dev/null -O2 -include
chrono -std=c++20 -xc++ /dev/null' (50 runs):

             65.83 msec task-clock:u # 0.968 CPUs utilized
( +- 0.47% )

 Performance counter stats for '/usr/bin/g++ -S -o /dev/null -O2 -include
chrono -std=c++17 -xc++ /dev/null' (50 runs):

             33.17 msec task-clock:u # 0.975 CPUs utilized
( +- 0.36% )

That adds to 1 CPU-second per 30 files. On a modern 4-core system (which is
probably the low-end for a developer) you need 100 files to add to 1 second of
compilation time.

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>.

<memory>, on the other hand:

c++17: 71.37 msec task-clock:u
c++20: 237.32 msec task-clock:u

That's 166 ms, or 1 second per 6 files. With clang using the same standard
library, the delta was over 230 ms. With libc++, the delta was 60 ms, but the
baseline was also higher at double the libstdc++ time.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DPG Cloud Engineering