17370845950

RTTI 的内存开销：vtable 膨胀和 type_info 对象

开启 RTTI 后，每个含虚函数的类的 vtable 会额外增加一个指向 std::type_info 对象的指针（通常在 vtable 开头或末尾，取决于 ABI）。这个 type_info 对象本身包含类名字符串（name() 返回值）、继承关系信息等，静态存储在只读段中。对于模板实例化多、继承层次深的项目，这些字符串和元数据会显著增加二进制体积——尤其在嵌入式或游戏引擎中，几 MB 的冗余符号可能直接触发 ROM 限制。

• Clang/GCC 下可用 readelf -s binary | grep type_info 或 nm -C binary | grep "typeinfo for" 查看生成了多少个 typeinfo 符号
• 禁用 RTTI 后，dynamic_cast 和 typeid 将无法链接（报 undefined reference to 'typeinfo for XXX'）
• 即使不显式用 typeid 或 dynamic_cast，只要类有虚函数且编译器认为“可能被 RTTI 查询”，就会生成 type_info

RTTI 的运行时开销：dynamic_cast 的遍历成本

dynamic_cast 在多继承或虚继承场景下不是常数时间操作。它需要在运行时遍历类的继承图谱，检查目标类型是否可达，并计算正确的指针偏移。最坏情况下（深度继承链 + 多重路径），耗时与继承层级呈线性甚至指数关系。这不是 CPU 指令级开销，而是实际可观测的延迟——比如在高频渲染循环中对每帧数百个对象做 dynamic_cast(obj)，可能成为性能瓶颈。

• 单继承且无虚基类时，dynamic_cast 通常只是加减法（快）
• 含虚继承时，必须查虚表偏移表（vbtable），每次 cast 都要跳转、查表、校验
• 用 static_cast 替代前，务必确保类型安全；否则 UB 比慢更严重

何时该用 -fno-rtti 关闭 RTTI

关闭 RTTI 不是“优化习惯”，而是明确放弃某些语言能力以换取确定性收益。以下场景值得认真考虑：

• 嵌入式裸机环境（无 libc++/libstdc++ 运行时，或需极致代码尺寸）
• 游戏引擎核心模块（如 ECS 组件系统已用 component_id 手动管理类型，完全绕过 dynamic_cast）
• 静态分析工具或 JIT 编译器后端（类型信息由自定义 IR 管理，标准 RTTI 冗余）
• 所有虚函数类都通过接口抽象、无需向下转型（即从不写 dynamic_cast，也从不取 typeid(x).name()）

注意：-fno-rtti 不影响 virtual 函数调用本身——虚函数表和动态分派照常工作。它只砍掉类型查询能力。

替代方案比关闭更常见：避免依赖 RTTI

多数项目不该直接关 RTTI，而应重构掉对它的依赖。真正的问题往往不在 RTTI 开销，而在滥用运行时类型检查暴露的设计缺陷：

class Shape {
public:
    virtual void draw() = 0;
    // ❌ 坏味道：用 dynamic_cast 模拟访问者模式
    virtual void accept(Renderer& r) { r.visit(*this); }
};

// ✅ 更轻量：用纯虚访问者 + 模板特化，零运行时成本
class Renderer {
public:
    virtual void visit(Circle&) = 0;
    virtual void visit(Rectangle&) = 0;
};

• 用 std::variant + std::visit 替代继承+dynamic_cast（C++17，无虚函数、无 RTTI）
• 用类型 ID 枚举 + switch 替代 typeid 字符串比较（更快、可内联、编译期检查）
• 若必须保留多态，优先用策略模式或组合，而非深继承树

RTTI 的真实代价，常常不是那几个字节或几纳秒，而是它纵容了本该在编译期解决的类型决策拖到运行时——这种设计债，比开关一个编译选项难收拾得多。