16 ms·

The hidden compile-time cost of C++26 reflection

60 points by SuperV1234 7mo ago

SuperV1234 7mo ago
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 And then benchmarked with: hyperfine "g++ -std=c++26 -fmodules -freflection ./main.cpp" The only "include" was import std;, nothing else. 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.
- SuperV1234 7mo ago
  Update: I had originally used a Docker image with a version of GCC built with assertions enabled, skewing the results. I am sorry for that. 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.
jstimpfle 7mo ago
The hidden compile-time cost of <insert almost any C++ feature>
- SuperV1234 7mo ago
  Nah, many great features are extremely cheap. E.g. constexpr, templates, fold expressions, equality operator defaulting, concepts...
  - kreco 7mo ago
    Yes, but they are still all hidden.
  - JamesTRexx 7mo ago
    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.
  - direwolf20 7mo ago
    constexpr means running code at compile time. template means duplicating lots of code lots of times. these are not cheap.
    - jeffbee 7mo ago
      Yeah this is the very first time I am hearing that templates are "extremely cheap". Template instantiation is pretty much where my project spends all of its compilation time.
      - SuperV1234 7mo ago
        It depends on what you are instantiating and how often you're doing so. Most people write templates in header files and instantiate them repeatedly in many many TUs. In many cases it's possible to only declare the template in the header, explicitly instantiate it with a bunch of types in a single TU, and just find those definitions via linker.
        jeffbee 7mo ago
        On the few times that I have looked at clang traces to try to speed up the build (which has never succeeded) the template instantiation mess largely arose from Abseil or libc++, which I can't do much about.
leni536 7mo ago
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 7mo ago
  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.
- surajrmal 7mo ago
  It also bloats binary size if you statically link libc++ because of localization, regardless if you care for it. This wasn't true for fmtlib because it doesn't support localization. stringstream has this same problem, but it's one of many reasons embedded has stuck with printf.
  - vitaut 7mo ago
    The binary bloat is also caused by unnecessary inlining and the linker eliminates most of it (but it's still annoying e.g. for godbolt). {fmt} supports a superset of std::format and std::print features including localization. stringstream's bloat is unrelated and mostly caused by large per-call binary code from concatenation-based API.
- SuperV1234 7mo ago
  The data was incorrect due to an oversight on my part (the Docker image I had used compiled GCC with internal assertions enabled). Including <print> is still very heavy, but not as bad as before (from ~840ms to ~508ms)
- vitaut 7mo ago
  std::print author here. Indeed, std::print shouldn't be expensive to compile, it's just a thin wrapper around a single type-erased function. The only reason why it is expensive in libstdc++ is that the type-erased function is inlined which goes against the proposed design but unfortunately can't be enforced via the standard wording and remains a Quality of Implementation (QoI) issue. Fortunately, libstdc++ is fixing this: https://gcc.gnu.org/pipermail/gcc-patches/2026-March/710275.html 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.
wjakob 7mo ago
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 7mo ago
  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.
  - direwolf20 7mo ago
    Parts of the language being in the std namespace isn't really a problem. An implementation is free to treat initializer lists as a built-in type.
    - panzi 7mo ago
      Is there an implementation that does that?
      - dataflow 7mo ago
        With std::nullptr_t on MSVC, it's always there without any includes.
  - dataflow 7mo ago
    > 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.) std::type_info? std::is_trivially_...?
dalvrosa 7mo ago
Nice to learn about hyperfine Compilation speed is a huge part of productivity and enjoying writing C++
ralferoo 7mo ago
"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 7mo ago
  It is quite common when being around WG21 stuff, just as info.
- dataflow 7mo ago
  > Not sure why they felt the need to abbreviate this It's super common terminology for people around those spaces; they probably didn't even think about whether they should abbreviate it.
- SuperV1234 7mo ago
  I've updated the article to say "translation unit" the first time "TU" is introduced. The data was also incorrect due to an oversight on my part, and it's now much more accurate and ~50% faster across the board.
r2vcap 7mo ago
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.
- SuperV1234 7mo ago
  Please check the article again -- I made a mistake in the original measurements (the Docker image I used had GCC compiled in debug mode) and now the (correct) times are ~50% faster across the board. Not free, still need to audit, but much better than before. Sorry.
zombot 7mo ago
How is it hidden if you can measure it?
wffurr 7mo ago
There are no zero cost abstractions: https://youtu.be/rHIkrotSwcc?si=oSBlKG9M_Ey8sVIU https://youtu.be/rHIkrotSwcc?si=oSBlKG9M_Ey8sVIU
- deleted 7mo ago
  [deleted]
- adev_ 7mo ago
  There is plenty of zero cost abstractions in C++ (and Rust to some extend). 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".
  - dataflow 7mo ago
    This is a pretty flippant response to a rather insightful point by someone who isn't exactly a newbie to the language. They understand very well the implications of move being nondestructive and the point they're making stands nevertheless.
    - adev_ 7mo ago
      Let me clarify something here (And my apologies if this looked a bit aggressive). There is always a cost to abstraction, and that can take different form. In C++, it is often build time (and/or complexity). And Chandler, in his talk, is perfectly right about that. But that does not change the validity of the C++ concept 'zero cost abstraction at *runtime*'. It is possible to get proper language abstractions while not sacrificing runtime performances. I did get sharp on his comment because this talk is constantly posted by a specific C crowd that profoundly hate any form of abstraction and use it as a totem to justify terrible development practices. If your language support zero cost abstraction and genericity, by the sake of god, use it... most of the time the impact in term compilation time is worth the benefits. unique_ptr is a beautiful example of that btw.
comandillos 7mo ago
just another piece to this jenga tower called c++. if you want reflection maybe just use a language that was designed with reflection support since the beginning.
SuperV1234 7mo ago
Update & Apology: 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.
HexDecOctBin 7mo ago
> Language features like templates are not the issue – the Standard Library is. 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.
Jyaif 7mo ago
> the more enjoyable and productive I find C++ as a language – insanely fast compilation times are a large part of tha +1 Rust really showed some of us how lucky we were with C++.

60 points by SuperV1234 7mo ago

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 And then benchmarked with: hyperfine "g++ -std=c++26 -fmodules -freflection ./main.cpp" The only "include" was import std;, nothing else. 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.

SuperV1234 7mo ago
Update: I had originally used a Docker image with a version of GCC built with assertions enabled, skewing the results. I am sorry for that. 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.

jstimpfle 7mo ago

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

SuperV1234 7mo ago
Nah, many great features are extremely cheap. E.g. constexpr, templates, fold expressions, equality operator defaulting, concepts...
- kreco 7mo ago
  Yes, but they are still all hidden.
- JamesTRexx 7mo ago
  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.
- direwolf20 7mo ago
  constexpr means running code at compile time. template means duplicating lots of code lots of times. these are not cheap.
  - jeffbee 7mo ago
    Yeah this is the very first time I am hearing that templates are "extremely cheap". Template instantiation is pretty much where my project spends all of its compilation time.
    - SuperV1234 7mo ago
      It depends on what you are instantiating and how often you're doing so. Most people write templates in header files and instantiate them repeatedly in many many TUs. In many cases it's possible to only declare the template in the header, explicitly instantiate it with a bunch of types in a single TU, and just find those definitions via linker.
      - jeffbee 7mo ago
        On the few times that I have looked at clang traces to try to speed up the build (which has never succeeded) the template instantiation mess largely arose from Abseil or libc++, which I can't do much about.

leni536 7mo ago

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 7mo ago
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.
surajrmal 7mo ago
It also bloats binary size if you statically link libc++ because of localization, regardless if you care for it. This wasn't true for fmtlib because it doesn't support localization. stringstream has this same problem, but it's one of many reasons embedded has stuck with printf.
- vitaut 7mo ago
  The binary bloat is also caused by unnecessary inlining and the linker eliminates most of it (but it's still annoying e.g. for godbolt). {fmt} supports a superset of std::format and std::print features including localization. stringstream's bloat is unrelated and mostly caused by large per-call binary code from concatenation-based API.
SuperV1234 7mo ago
The data was incorrect due to an oversight on my part (the Docker image I had used compiled GCC with internal assertions enabled). Including <print> is still very heavy, but not as bad as before (from ~840ms to ~508ms)
vitaut 7mo ago
std::print author here. Indeed, std::print shouldn't be expensive to compile, it's just a thin wrapper around a single type-erased function. The only reason why it is expensive in libstdc++ is that the type-erased function is inlined which goes against the proposed design but unfortunately can't be enforced via the standard wording and remains a Quality of Implementation (QoI) issue. Fortunately, libstdc++ is fixing this: https://gcc.gnu.org/pipermail/gcc-patches/2026-March/710275.html 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.

wjakob 7mo ago

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 7mo ago
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.
- direwolf20 7mo ago
  Parts of the language being in the std namespace isn't really a problem. An implementation is free to treat initializer lists as a built-in type.
  - panzi 7mo ago
    Is there an implementation that does that?
    - dataflow 7mo ago
      With std::nullptr_t on MSVC, it's always there without any includes.
- dataflow 7mo ago
  > 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.) std::type_info? std::is_trivially_...?

dalvrosa 7mo ago

Nice to learn about hyperfine Compilation speed is a huge part of productivity and enjoying writing C++

ralferoo 7mo ago

"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 7mo ago
It is quite common when being around WG21 stuff, just as info.
dataflow 7mo ago
> Not sure why they felt the need to abbreviate this It's super common terminology for people around those spaces; they probably didn't even think about whether they should abbreviate it.
SuperV1234 7mo ago
I've updated the article to say "translation unit" the first time "TU" is introduced. The data was also incorrect due to an oversight on my part, and it's now much more accurate and ~50% faster across the board.

r2vcap 7mo ago

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.

SuperV1234 7mo ago
Please check the article again -- I made a mistake in the original measurements (the Docker image I used had GCC compiled in debug mode) and now the (correct) times are ~50% faster across the board. Not free, still need to audit, but much better than before. Sorry.

zombot 7mo ago

How is it hidden if you can measure it?

wffurr 7mo ago

There are no zero cost abstractions: https://youtu.be/rHIkrotSwcc?si=oSBlKG9M_Ey8sVIU https://youtu.be/rHIkrotSwcc?si=oSBlKG9M_Ey8sVIU

deleted 7mo ago
[deleted]
adev_ 7mo ago
There is plenty of zero cost abstractions in C++ (and Rust to some extend). 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".
- dataflow 7mo ago
  This is a pretty flippant response to a rather insightful point by someone who isn't exactly a newbie to the language. They understand very well the implications of move being nondestructive and the point they're making stands nevertheless.
  - adev_ 7mo ago
    Let me clarify something here (And my apologies if this looked a bit aggressive). There is always a cost to abstraction, and that can take different form. In C++, it is often build time (and/or complexity). And Chandler, in his talk, is perfectly right about that. But that does not change the validity of the C++ concept 'zero cost abstraction at *runtime*'. It is possible to get proper language abstractions while not sacrificing runtime performances. I did get sharp on his comment because this talk is constantly posted by a specific C crowd that profoundly hate any form of abstraction and use it as a totem to justify terrible development practices. If your language support zero cost abstraction and genericity, by the sake of god, use it... most of the time the impact in term compilation time is worth the benefits. unique_ptr is a beautiful example of that btw.

comandillos 7mo ago

just another piece to this jenga tower called c++. if you want reflection maybe just use a language that was designed with reflection support since the beginning.

SuperV1234 7mo ago

Update & Apology: 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.

HexDecOctBin 7mo ago

> Language features like templates are not the issue – the Standard Library is. 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.

Jyaif 7mo ago

> the more enjoyable and productive I find C++ as a language – insanely fast compilation times are a large part of tha +1 Rust really showed some of us how lucky we were with C++.