"I can recompile the entire thing from scratch in ~4.3s. That’s around ~900 TUs, including external dependencies, tests, and examples"

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.

• pjmlp

  today at 11:08 AM

  It is quite common when being around WG21 stuff, just as info.

libstdc++'s <print> is very heavy, reflection or not. AFAIK there is no inherent reason for it to be that heavy, fmtlib compiles faster.

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

• craftit

  today at 10:39 AM

  I don't know the exact details, but I have heard (on C++ Weekly, I believe) that it offers some advantages when linking code compiled with different compiler versions. That said, I normally avoid it and use fmtlib to avoid the extra compile time. So it isn't clear if it is a win to me. Header-only libraries are great on small projects, but on large codebases with 1000's of files, it really hits you.

Yuck. I’ve already noticed compilation times increasing from C++17 to C++20, and this feature makes it much worse. I guess I’ll need to audit any reflection usage in third-party dependencies.

I am very worried by feature creep in libc++ and libstdc++ and the harm that this inflicts on the wider C++ ecosystem. Transitive inclusion of large parts of the STL, and entangling of STL with core language features are both extremely bad. This should IMO be topic #1 of the committee but is barely even noticed. The mantra "It's okay, modules will save us" is naive and will not work.

• CoastalCoder

  today at 11:31 AM

  I'm pretty late to this discussion, but...

  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.

Nice to learn about hyperfine

Compilation speed is a huge part of productivity and enjoying writing C++

I ran some more measurements using import std; with a properly built module that includes reflection.

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.

How is it hidden if you can measure it?

The hidden compile-time cost of <insert almost any C++ feature>

• SuperV1234

  today at 11:15 AM

  Nah, many great features are extremely cheap. E.g. constexpr, templates, fold expressions, equality operator defaulting, concepts...

  • JamesTRexx

    today at 12:09 PM

    Until you try to add / modify a feature of the software and run into confusing template or operator or other C++ specific errors and need to deconstruct a larger part of the code to find (if possible) out where it comes from and spend even more time trying to correct it.

    C++ is the opposite of simplicity and clarity in code.

  • kreco

    today at 11:31 AM

    Yes, but they are still all hidden.