C++26 Reflection Benchmarks Reveal Hidden Costs in Modern C++ Development

Vittorio Romeo, a prominent C++ developer and author, has published a detailed benchmark measuring the real-world compile-time costs of C++26 reflection, specifically for enum-to-string conversion. His findings provide crucial insights for developers considering adopting this new C++ feature in production codebases.

The benchmark compares three approaches to converting enum values to their string representations: C++26 reflection using the new header, the enchantum library for C++17, and traditional X-macro techniques using preprocessor directives.

"The cost of C++26 reflection is not the reflection. It's ," Romeo writes in his analysis. "The reflection algorithm itself seems to be quite fast. The reason a reflection-based to_string ends up ~7x slower to compile than the bare-metal const char* X-macro variant is almost entirely (and its transitively-included headers)."

Benchmark Methodology

Romeo created several translation units with enum classes of varying sizes (4, 16, 64, 256, and 1024 enumerators) and measured compile times for each approach. He used GCC 16.1.1 in a controlled Fedora 44 Docker environment to ensure consistent measurements.

The results show that:

• The reflection algorithm itself scales at approximately 0.07 ms per enumerator
• Including the header costs about 155 ms per translation unit over baseline
• X-macros with const char* remain the fastest approach (26.9 ms for N=16)
• enchantum has significant overhead due to scanning its entire configured range

Scaling Impact in Real Projects

While individual translation unit compile times may seem small, Romeo emphasizes that these costs compound significantly in large codebases. For a project with 500 translation units using an enum with 16 values:

• X-macro (const char*): ~13 seconds total
• X-macro (string_view): ~69 seconds total
• enchantum: ~85 seconds total
• Reflection: ~94 seconds total

"A few hundred milliseconds per TU turns into over a minute of compile time at the project level," Romeo explains. "That's the difference between a sub-15-second clean build and a minute and a half."

Optimization Strategies

The benchmark reveals several strategies for mitigating reflection's compile-time costs:

1. Precompiled Headers (PCH): Using PCH for provides approximately 2.3x speedup, making reflection the fastest of the tested approaches
2. Strategic Include Placement: Avoid including reflection headers in public interfaces to minimize transitive dependencies
3. Conditional Compilation: Consider using reflection only where its benefits outweigh the costs

Interestingly, C++20 modules in GCC 16 actually worsened performance by approximately 2.2x compared to traditional includes, though Romeo notes this may improve as module implementations mature.

Market Implications

Romeo's work provides valuable data for the C++ ecosystem as reflection becomes more widely available. His analysis suggests that while reflection offers compelling ergonomics benefits, the current implementation may create significant compile-time burdens in large projects.

"I'm still excited about reflection," Romeo concludes. "It will replace a lot of ugly macro boilerplate and unlock libraries that weren't really possible before. But until gets lighter (or until modules become ubiquitous), every project that adopts it should know what the bill looks like."

For developers exploring C++26 reflection, Romeo's full benchmark results and source code are available on GitHub. His previous article on reflection costs, "The Hidden Compile-Time Cost of C++26 Reflection," provides additional context on these findings.

Romeo also offers C++ training and consulting through romeo.training and can be reached at mail (at) vittorioromeo (dot) com or on Twitter.