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<Light*>(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 函数调用本身——虚函数表和动态分派照常工作。它只砍掉类型查询能力。
立即学习“C++免费学习笔记（深入）”；
替代方案比关闭更常见：避免依赖 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 的真实代价，常常不是那几个字节或几纳秒，而是它纵容了本该在编译期解决的类型决策拖到运行时——这种设计债，比开关一个编译选项难收拾得多。
