虚函数调用开销在于vptr与vtable两级间接寻址、vptr内存占用、无法内联及分支预测失败；std::variant避免虚表但需tag检查，误用会导致冗余比较与代码膨胀；concepts仅编译期约束，不解决运行时多态性能问题。
虚函数调用的实际开销在哪
虚函数不是“慢”，而是引入了两级间接寻址：先通过 this 指针拿到对象头里的 vptr，再用该指针查 vtable 中对应函数的地址，最后跳转执行。现代 CPU 的分支预测器对规律性虚调用（如循环中统一类型）能较好优化，但跨类型频繁切换时容易 mispredict，导致流水线冲刷。
关键点：
-
vptr占用每个对象 8 字节（64 位系统），继承链越深、虚基类越多，对象体积膨胀越明显 - 编译器无法内联虚函数（除非 devirtualization 成功，但需 LTO + 全局可见定义，且不适用于动态加载的插件）
- 调试模式下无优化时，虚调用比普通函数慢 3–5 倍；O2 下差距缩至 1.2–1.8 倍（取决于是否命中缓存、是否触发预测失败）
std::variant 替代虚函数时的性能陷阱
std::variant 是值语义的标签联合体，运行时不依赖虚表，但每次访问都需 std::visit 或 std::get_if 进行 tag 检查和分支跳转。它快在无指针间接、无 vptr 开销，慢在缺乏编译期单态性保证。
常见误用：
立即学习“C++免费学习笔记（深入）”；
- 用
std::visit([](auto&& x) { ... }, v)写泛型 lambda —— 看似简洁，实则强制为每个分支生成独立实例，代码体积暴涨，且无法复用已有函数对象 - 在 tight loop 中反复
std::get_if<t>(&v)</t>而非一次std::visit处理全部逻辑，造成冗余 tag 比较 - 忽略
std::variant的构造/赋值开销：内部需 placement-new + 析构调度，比 raw struct 拷贝重
std::variant<int, std::string, double> v = 42;
// ✅ 推荐：一次 visit 完成所有处理
std::visit([](const auto& x) {
using T = std::decay_t<decltype(x)>;
if constexpr (std::is_same_v<T, int>) {
// 编译期分发，无运行时分支
} else if constexpr (std::is_same_v<T, std::string>) {
// ...
}
}, v);
<p>// ❌ 避免：重复 tag 检查
if (auto<em> p = std::get_if<int>(&v)) { /</em> ... <em>/ }
else if (auto</em> p = std::get_if<std::string>(&v)) { /<em> ... </em>/ }</p>Concepts 不解决运行时多态性能问题
Concepts 是编译期约束机制，用于限定模板参数必须满足的接口要求。它本身不生成任何运行时代码，也不影响二进制大小或执行路径 —— 它只让错误提前到编译阶段，并支持更精确的重载决议。
典型混淆：
- 以为写
template<typename t> requires Drawable<t></t></typename>就能替代虚函数 —— 实际上这只是泛型编程，生成的是多个独立函数实例，与多态无关 - 试图用 Concepts 强制“统一接口”却仍靠运行时类型判断（比如把
std::variant传给 concept-constrained 函数）—— concepts 对variant本身不做约束，只能约束其成员类型 - 忽略 SFINAE/Concepts 导致的编译时间上升：约束越复杂，实例化检查越耗时，尤其在 header-only 库中明显
怎么选：看控制流模式而非抽象层级
性能差异最终取决于你如何组织控制流。虚函数适合“一个接口、多种实现、类型在运行时动态混合”的场景；std::variant 更适合“有限几种类型、操作集中在一处、类型在逻辑上可枚举”的情形。
决策 checklist：
- 是否需要堆分配 + 多态销毁？→ 必须用虚析构，
std::variant不适用 - 类型集合是否固定且数量 ≤ 10？→
std::variant通常更优（cache 局部性好，无指针跳转） - 是否存在跨 shared library 边界的多态扩展？→ 只能用虚函数，
std::variant类型必须在编译期完全可见 -
热点路径中是否反复调用同一虚函数（如渲染循环中的
draw()）？→ 查看 perf report 中call指令的 cycles 和 branch-misses，若 mispredict > 15%，考虑 monomorphization 或 arena 分配+类型分离
最常被忽略的一点：虚函数表本身不慢，慢的是你没让编译器知道“这里其实只有一种类型”。哪怕只是临时加个 [[likely]] 或局部 static_cast，有时比换方案更有效。
