C++26 反射的真实成本：枚举转字符串转换基准测试

将枚举转换为字符串通常被认为是反射的“hello world”。虽然看起来很简单，但它是专业 C++ 项目中日志记录、序列化和调试的普遍需求。随着 GCC 16 的正式发布，开发者现在有了具体的机会来衡量 C++26 反射相对于传统替代方案的表现。

Vittorio Romeo 最近进行的基准测试强调了一个关键区别：使用反射的成本不在于反射算法本身，而在于支持它所需的底层架构。

比较三种实现策略

为了确定编译时影响，对三种不同的枚举转字符串转换方法进行了基准测试：

1. C++26 反射

使用 <meta> 头文件，这种方法最符合人体工程学。它不需要宏，并且适用于任何枚举类型，无论其结构如何。

template <typename T>
    requires std::is_enum_v<T>
constexpr std::string_view to_enum_string(T val)
{
    template for (constexpr auto e : 
        std::define_static_array(std::meta::enumerators_of(^^T)))
    {
        if (val == [:e:])
            return std::meta::identifier_of(e);
    }
    return "<unknown>";
}

2. enchantum (C++17)

该库使用 __PRETTY_FUNCTION__ 解析技巧来实现类似于反射的行为，而无需在调用点使用反射标志或宏。

3. X-Macros (预处理器方法)

这种 C 风格的解决方案使用单个宏列表来展开为枚举定义和用于字符串转换的 switch 语句。它是最“底层”的方法，如果使用 const char* 而不是 std::string_view，通常可以实现零标准库包含。

基准测试结果

基准测试是在 13 代 i9-13900K 上使用 GCC 16.1.1 进行的。结果显示，随着枚举量 (N) 的增加，每个翻译单元 (TU) 的总编译时间呈现出鲜明的对比。

N X-macro (const char*) X-macro (string_view) enchantum Reflection
Baseline 25.7 ms 25.7 ms 25.8 ms 25.7 ms
Header only 25.7 ms 136.0 ms 147.1 ms 180.8 ms
4 26.6 ms 137.6 ms 170.6 ms 186.7 ms
1024 54.7 ms 204.5 ms 272.0 ms 255.0 ms

规模扩展性的关键发现

  • 头文件税： 最显著的发现是，包含 <meta> 的成本比基准线高出每个 TU 约 155 ms。
  • 算法效率： 一旦包含了头文件，反射算法非常快，其扩展性约为每个枚举量 0.07 ms，这与 X-macro 版本中手工编写的 switch 几乎相同。
  • enchantum 扩展性： 与其他方法不同，enchantum 的扩展性取决于配置的扫描范围而非枚举量的数量，这使得它对于小型枚举来说相对昂贵。

优化反射性能

鉴于 <meta> 头文件的高昂成本，该研究探索了使用预编译头文件 (PCH) 和 C++20 Modules 来减轻开销。

  • PCH (获胜者)： 预编译 <meta> 导致了 2.3 倍的加速，将 4 个枚举量的枚举的编译时间从 187 ms 降至 81 ms。使用 PCH，反射比 enchantum 和 string_view 版本的 X-macro 都要快。
  • Modules (令人惊讶的结果)： 令人惊讶的是，在 GCC 16 中，C++20 modules 实际上比普通包含方式慢了大约 2.2 倍。这表明当前 GCC 16 的实现中，模块加载尚未优化到 PCH 的水平。

现实世界的影响

虽然每个 TU 几百毫秒可能看起来微不足道，但其影响会随着项目规模线性扩展。在一个拥有 500 个 TU 的代码库中，X-macro 方法 (13 秒) 与反射方法 (94 秒) 之间的差异可能意味着快速增量构建与令人沮丧的缓慢构建之间的区别。

给开发者的建议

  1. 优先使用 PCH 而非 Modules： 目前，如果你正在使用 GCC 16，请使用 PCH 来处理 <meta>。
  2. 最小化头文件暴露： 尽可能将枚举转字符串的头文件放在包含图谱的底层，以避免传递性包含开销。
  3. 对于极端性能需求，坚持使用 X-Macros： 在对构建时间要求极高的项目中（例如构建时间需在 10 秒以内），尽管缺乏人体工程学，X-macros 仍然是更优的选择。
  4. 库作者请注意： 避免通过公共头文件暴露反射，因为这会迫使每个使用者都必须支付 <meta> 头文件的税收。

社区观点

该基准测试引发了开发者关于人体工程学与性能之间的权衡讨论。一些人指出，虽然反射是一个强大的工具，但使用外部代码生成（一个处理源代码的独立程序）的“C 风格”方法仍然是一种高度可调试且高效的替代方案。

其他人则质疑将这些结果推广到其他编译器的有效性，指出随着 Clang 的 C++26 反射实现趋于成熟，性能特征可能会有显著不同。

正如作者总结道：

C++26 反射的成本不在于反射。而在于 <meta>。

Sources