In 30 years of using C++ this is the first time I've ever come across "translation unit" being abbreviated to TU and it took a bit of effort to figure out what the author was trying to say. Not sure why they felt the need to abbreviate this when they explain PCH for instance, which is a far more commonly used term.
Thought I'd add the context here to help anyone else out.
It's super common terminology for people around those spaces; they probably didn't even think about whether they should abbreviate it.
I've fully updated the article with new benchmarks.
A reader pointed out that the GCC 16 Docker container I originally used was built with internal compiler assertions enabled, skewing the data and unfairly penalizing GCC.
I've re-measured everything on a proper release build (Fedora 44), and the compile times are ~50% faster across the board.
The article now reflects the accurate numbers, and I've added an appendix showing the exact cost of the debug assertions.
I sincerely apologize for the oversight.
<meta> is another question, it depends on string_view, vector, and possibly other parts. Maybe it's possible to make it leaner with more selective internal deps.
Fortunately, libstdc++ is fixing this: https://gcc.gnu.org/pipermail/gcc-patches/2026-March/710275..... There is still more work to optimize the includes but it's a good start.
Including <print> is still very heavy, but not as bad as before (from ~840ms to ~508ms)
I was somewhat horrified to discover that the STL ended up with a special role in the language spec. (IIRC, one of the tie-ins is initializer lists.)
IMHO it's far wiser to leave the standard library as something that isn't needed by the core language, and where users can (at least in principle) provide their own alternative implementation without needing compiler hacks.
I.e., those details are inherent in the definition of "library" in the C/C++ world.
std::type_info? std::is_trivially_...?
And given how much of the language's spec is "The behavior is undefined when combining these two features," it's not really a tome that is safely ignored.
At this point, I cannot recommend C++ on any new project that some external factor such as safety certification (which "solves" the problem by adding yet more pages of stuff a developer must not do that the language syntactically supports and compiles but generates garbage output) isn't forcing my hand on.
As of 2026 C has eclipsed C++ in popularity on the TIOBE index; anecdotally, roboticists I've chatted with have told me they prefer to write core functionality as C modules and then weld them together into high-level behavior with a terser scripting DSL over trying to write the whole thing in C++ and hoping there's no undefined behavior hidden in the cracks that multiple layers of linters, sanitizers, and auto-certifiers have missed.
I first created the module via:
g++ -std=c++26 -fmodules -freflection -fsearch-include-path -fmodule-only -c bits/std.cc
hyperfine "g++ -std=c++26 -fmodules -freflection ./main.cpp"
These are the results:
- Basic struct reflection: 352.8 ms
- Barry's AoS -> SoA example: 1.077 s
Compare that with PCH:
- Basic struct reflection: 208.7 ms
- Barry's AoS -> SoA example: 1.261 s
So PCH actually wins for just <meta>, and modules are not that much better than PCH for the larger example. Very disappointing.
Modules are actually not that bad with a proper version of GCC. The checking assertions absolutely crippled C++23 module performance in the original run:
Modules (Basic 1 type): from 352.8 ms to 279.5 ms (-73.3 ms) Modules (AoS Original): from 1,077.0 ms to 605.7 ms (-471.3 ms, ~43% faster)
Please check the update article for the new data.
Not free, still need to audit, but much better than before. Sorry.
What sins does STL commits that make it slow if templates themselves are not slow, and what kind of template code doesn't bloat compile times? In my experience, C++ libraries are usually one order of magnitude or more slower to compile than equivalent C ones, and I always chalked it upto the language.
Compilation speed is a huge part of productivity and enjoying writing C++
This talk just point that unique_ptr is not one of them due to the side effect of C++ move semantics being non destructive.
People that do not understand that should honestly stop to use it as an argument in favor of "there is no zero cost abstractions".
C++ is the opposite of simplicity and clarity in code.
+1
Rust really showed some of us how lucky we were with C++.