> This was a single paragraph in a large blog post, why the heck would I be including a detailed analysis of how I reached that conclusion? On one out of dozens of compile-time regressions I investigated? Something I do all the time, and am likely an expert on?

Yes, when you make a questionable claim and you do not provide any evidence or whatsoever on how you reached to that conclusion, you should be ready to be challenged. Especially given the fact that this is a _technical_ blog targeted to people with technical expertise.

You also take the occasion in the article to subtly confuse the uneducated readers by saying

> In particular, the large regression on the right is due to enabling C++17 by default.

as it is some sort of an universal truth that all C++ code bases will risk if they switch to C++17, which I will counterpoint later in my comment with a real-world multi-million LoC C++ project that includes virtually every C++ header in existence (*).

You sort of try to support that claim by saying that bigger sized STL implementation from C++17 is the culprit

> The close to two times slowdown in 7zip O0 builds comes down to STL headers becoming 2-3 times as large in C++17.

and at which point you really got me puzzling because I've worked on C++14 codebases which made the transition to C++17, and some even to C++20, and I never recall discussions taking place because of the build time regression as big as implied by the article. This wouldn't go unnoticed on multi-million LoC projects in a real-world.

But you also continue with a snarky comment such as

> While this is sad, and I had to edit out some choice words on the C++ standardization committee (I hear that this gets even worse in C++20), at least this does not affect non-clang compilers (e.g. Rust) and C code.

You don't provide any constructive criticism nor have I seen you opening the bug for further investigation. All those things create a bad impression and it doesn't seem that your comments are coming from a good place either. It reads as a very biased PoV which is sort of a problem given that you're professionally involved with the work on LLVM, clang and Rust, and along the way you're being paid by RedHat for that type of work.

(*) I've cloned https://github.com/mysql/mysql-server. Whole codebase is roughly around 3M lines of C and C++ code (among other types of source code). I did not do a very scientific experiment because initial results weren't matching what the article has shown but I've ran the RelWithDebInfo builds against {clang, gcc} x {C++14, C++17} and I've repeated that experiment with two different versions of gcc and clang. TL;DR neither clang or gcc build variant do not show a "regression" larger than ~5% in wall-clock time.

1a8a111d8f855a31d0aeffc8f02309b2b82dd410 was an actual point in time when MySQL transitioned from C++14 to C++17, and this commit was used as a base for C++17 builds. 1a8a111d8f855a31d0aeffc8f02309b2b82dd410~1 was used for C++14 builds. No ccache was involved or whatsoever. Everything was dockerized.

Build with gcc-7.3.1:
6m33s (C++14) vs 6m55s (C++17)

Build with clang-5.0.2
3m52s (C++14) vs 3m58s (C++17)

Build with gcc-9.3.1
5m6s (C++14) vs 5m22s (C++17)

Build with clang-8.0.0
4m39s (C++14) vs 4m49s (C++17)