mysql-server

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)

UTF-8. The RFCs are explicit about that. [4] [5] (search for D800) Maybe you're thinking of CESU-8, though that's not intended for interchange. [6] > Only "recently" have longer UTF-8 sequences (aka. emojis) become widespread enough that this became a problem. Not supporting Unicode properly has always been problematic; it's just that bug reports from affected users rarely reached the right people. Emojis have done the world a favour in making less competent developers actually notice their bugs in basic text handling. > Yes, it could have been avoided And was, by most developers. > they probably just wanted to optimize a bit. They apparently altered a config number [1], so it wasn't an optimization decision; the code at the time still had support for 6-byte utf8 [7]. I would guess that they found a bug in their support for longer utf-8 sequences/conversion and took the hacky way out. [1] https://github.com/mysql/mysql-server/commit/43a506c0ced0e6e... [2] https://unicode.org/faq/utf_bom.html [3] https://en.wikibooks.org/wiki/Unicode/Versions [4] https://datatracker.ietf.org/doc/html/rfc2044 [5] https://datatracker.ietf.org/doc/html/rfc3629 [6] https://www.unicode.org/reports/tr26/tr26-4.html [7] https://github.com/mysql/mysql-server/blob/43a506c0ced0e6ea1...