运行时使用constexpr与非constexpr查找表的区别是什么？

核心问题答疑 #

1. constexpr查找表的存储逻辑 #

当你对constexpr数组存在运行时访问时，编译器会将其放入二进制文件的只读数据段(.rodata)，你在汇编中看到的.LC0就是这部分数据的定义。它不需要在运行时拷贝生成，程序加载时由操作系统直接映射到进程的只读内存空间，全程没有运行时初始化开销。
只有当访问数组的索引是编译期常量时，编译器才会直接把对应值硬编码到指令中，完全跳过内存访问。

2. constexpr表和普通运行时表的差异 #

和普通运行时构造的查找表相比，constexpr表有几个核心区别：

• 无初始化开销：普通全局非const数组、局部数组、动态分配的数组都需要在运行时写入初始值，constexpr表的内容编译期就已经确定，直接打包进二进制
• 内存属性不同：constexpr表默认是只读的，存放在.rodata段，不会被意外修改，也不会占用栈/堆空间
• 优化自由度更高：编译期可见的取值让编译器可以做更多激进优化，比如索引范围校验消除、常量折叠、循环展开时代替为立即数等

3. constexpr查找表的实际性能收益 #

如果你的索引是纯运行时传入的，单从单次访问开销看，读.rodata的开销和读普通内存差异很小，但整体收益仍然明显：

• 无分支开销：你原来的if/switch写法依赖分支预测，一旦预测失败会产生至少10~20个时钟周期的惩罚，查表是无分支操作，性能稳定
• 没有初始化成本：如果表的规模较大，避免运行时构造的收益会非常明显
• 极端场景下的优化空间：当编译器可以推导出索引的可能范围时，会直接把查表操作优化为硬编码的立即数，完全消除内存访问

优化实现方案 #

针对你的场景，可以按如下方式实现，兼顾易用性和优化空间：

#include <cstdint>
#include <array>

enum class Types : uint8_t {
    Char,
    Int
};

// 用std::array包装的constexpr查找表，operator[]原生支持constexpr调用
constexpr std::array<int, 2> typeSizes = {
    sizeof(char),
    sizeof(int)
};

// 可选：封装取值函数，自动适配编译期/运行时索引
constexpr int getTypeSize(Types t) {
    // 编译器内置判断：如果t是编译期常量，直接返回硬编码值
    if (__builtin_constant_p(t)) {
        switch(t) {
            case Types::Char: return sizeof(char);
            case Types::Int: return sizeof(int);
            default: __builtin_unreachable();
        }
    }
    // 运行时索引走查表逻辑
    return typeSizes[static_cast<uint8_t>(t)];
}

使用时两种写法都支持：

// 原期望的调用形式
sum += typeSizes[static_cast<uint8_t>(type)];
// 封装后的调用形式，优化机会更多
sum += getTypeSize(type);

如果你的enum取值数量很少（比如小于等于3个），编译器在高优化等级下甚至会自动把查表操作转换为等价的无分支算术运算，完全消除内存访问开销。

内容的提问来源于stack exchange，提问作者Bioliquid