c++的RTTI (运行时类型信息) 有哪些开销？ (何时应该关闭它)_技术教程

c++kquote>RTTI 的主要开销包括内存（vtable 膨胀、type_info 字符串增大二进制体积）和运行时（dynamic_cast 在多/虚继承下需遍历继承图，延迟可观）；禁用 -fno-rtti 可节省空间并杜绝相关开销，但会移除 dynamic_cast 和 typeid 支持，适用于嵌入式、游戏引擎核心等明确无需运行时类型查询的场景。

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;
};