`<chrono>`: Can we avoid including `<format>`?

[StephanTLavavej]

On reddit, u/tgolyi reports:

std::format is very cool, but why did you include <format> to <chrono>? This change alone slowed down compilation for our project by 20%. Is it required by the standard now to include <format> (to support std::formatter specialization)? It's just that <chrono> is included by so many other headers like <mutex> and <thread> and Qt too.

Separately from any throughput improvements for <format>, I believe it should be possible to remove this dependency:

STL/stl/inc/chrono

Lines 37 to 40 in 4c862ee

	#ifdef __cpp_lib_format
	#include <format>
	#include <iomanip>
	#endif // defined(__cpp_lib_format)

The fix would presumably involve some combination of:

• Forward declarations (of formatter etc.)
• Extracting common machinery to a centralized header somewhere (used sparingly, since this costs throughput)
• Possibly templatizing stuff so that it isn't instantiated until needed (need to follow the Standard's lookup rules)

Related to DevCom-10046069 "Including chrono and compiling with -std:c++20 is ten time slower than before" and internal VSO-1543202 / AB#1543202 .

[frederick-vs-ja]

Including <format> not only slows down compilation, but also drags in some codes for dynamic initialization (https://godbolt.org/z/8njf5E85q https://godbolt.org/z/x98Tqexaq).

Oh... it seems that this issue disappears if the workaround for #2329 is removed. This issue has been fixed reduced, but not fixed, by #2496.

[frederick-vs-ja]

Partially addressed by #2600.

Implementations of some operator<<s in <chrono> are currently dependent on std::format, which is requiring almost everything in <format>. IMO removing the dependence on <format> essentially needs implementing these operator<<s in some alternative ways.