“虚函数调用有性能开销”，这句话你肯定听过，但到底慢多少、为什么慢、什么时候需要担心，这些问题很多人其实说不清楚。
虚函数调用大约需要24个时钟周期，而普通函数调用只需要4.2个周期，粗略算下来，慢了将近6倍。
6倍，听起来很吓人。但这个数字有多大意义？虚函数到底是怎么调用的，开销从哪来？搞清楚这些，你才能知道什么时候该优化，什么时候压根不用管。
虚函数调用的完整过程
先看一段最简单的多态代码：
classBase{public:virtualvoidfoo(){/* ... */}};classDerived:publicBase{public:voidfoo()override{/* ... */}};voidcall(Base*obj){obj->foo();// 这里发生了什么？}当你写下obj->foo()这行代码，编译器没法在编译期知道obj指向的到底是Base对象还是Derived对象，所以它没法直接生成一条"跳转到某个固定地址"的指令。
那怎么办？答案是查表。
vtable和vptr
编译器为每个有虚函数的类生成一张表，叫vtable（虚函数表），表里存的是函数指针，每个虚函数占一个槽位。
Base的vtable: +--------+ | &Base::foo | +--------+ Derived的vtable: +--------+ | &Derived::foo | +--------+每个对象的开头（这是GCC、Clang、MSVC等主流编译器的通用实现），编译器会偷偷塞一个指针，叫vptr（虚表指针），指向这个对象所属类的vtable。
Base对象的内存布局: +--------+--------+ | vptr | data | +--------+--------+ | v Base的vtable Derived对象的内存布局: +--------+--------+ | vptr | data | +--------+--------+ | v Derived的vtable一次虚函数调用的完整过程
当CPU执行obj->foo()时，实际发生的事情分四步：首先从obj指向的内存开头取出vptr的值，然后根据foo在vtable中的槽位计算偏移，接着从vtable对应位置读出实际要调用的函数地址，最后跳转到这个地址执行。
用伪代码表示就是这样：
// obj->foo() 实际上被编译器转换成：void*vptr=*(void**)obj;// 1. 读vptrvoid*func_addr=vptr[0];// 2-3. 查表取函数地址func_addr(obj);// 4. 间接调用对比一下普通函数调用：
// 普通调用：obj.foo()Base::foo(obj);// 直接跳转到固定地址差别一目了然：普通调用是直接跳转，地址在编译期就确定了；虚函数调用是间接跳转，要先查表才能知道跳去哪，这个"先查表再跳转"的过程，就是虚函数调用开销的根源。
开销从哪来？
虚函数调用比普通调用慢，但"慢"的原因不是单一的，而是四个因素叠加在一起。
1. 内存访问开销
虚函数调用至少需要两次额外的内存读取：第一次读vptr，第二次读vtable里的函数地址，而内存访问比寄存器操作慢得多，如果这两次读取都不在CPU缓存里（也就是发生了cache miss），惩罚就更大。
好消息是，如果你反复调用同一个对象的虚函数，vptr和vtable大概率已经在L1 cache里了，这时候内存访问开销几乎可以忽略不计。
2. 间接分支预测
现代CPU有分支预测器，普通函数调用的目标地址是固定的，预测器很容易猜对，CPU可以提前把指令加载到流水线里，执行效率很高。
但虚函数调用的目标地址是运行时才知道的，预测器就不太好使了。如果你有一个数组，里面装着各种不同派生类的指针，然后循环调用它们的虚函数——恭喜你，这是间接分支预测器的噩梦，预测失败一次，CPU流水线就要清空重来，惩罚可能高达10-30个时钟周期。
3. 内联失效
这是最隐蔽、但往往也是影响最大的一个因素。
编译器很擅长优化，其中最强力的优化之一就是内联：把函数体直接展开到调用点，省掉函数调用的开销，还能进一步做常量传播、死代码消除等优化。
但虚函数通常没法内联——编译器不知道运行时会调用哪个版本的函数，没法展开。
// 如果foo是普通函数，编译器可以这样优化：voidcall(Base*obj){// obj->foo() 被内联展开// foo的函数体直接出现在这里// 还可以进一步优化...}// 如果foo是虚函数，编译器只能老老实实：voidcall(Base*obj){// 查表，间接调用，没法内联}这意味着什么？如果你有一个非常短小的函数，比如只返回一个成员变量，普通函数可以被内联成一次内存读取，而虚函数版本要先查表、再调用、再返回，开销差了一个数量级，这个差距在getter/setter这类简单函数上尤其明显。
4. 缓存局部性
如果你的程序用多态处理大量不同类型的对象，这些对象的vtable散落在内存各处，频繁切换会导致指令缓存（icache）和数据缓存（dcache）的命中率下降，这个开销比较隐蔽，在microbenchmark里不容易看出来，但在真实程序中可能很明显。
到底慢多少？
说了这么多，给点具体数字。Johnny’s Software Lab做过一个测试，用2000万个对象调用虚函数：
| 场景 | 虚函数调用 | 普通调用 | 差距 |
|---|---|---|---|
| 短函数（函数体很轻） | 153ms | 126ms | 慢21% |
| 长函数（函数体较重） | 几乎相同 | 几乎相同 | <1% |
另一个在Apple M4上的测试显示，在缓存命中良好的情况下，虚函数调用的额外开销可低至约0.13纳秒/次。
虚函数调用约24周期 vs 普通调用4.2周期，差了大约5-6倍。
这些数字看起来差别挺大，但要注意三点：
- 短函数场景：虚函数调用本身的开销占了大头，所以差距明显（18%），但绝对时间很小
- 长函数场景：函数体执行时间远大于调用开销，虚函数那点额外开销就被稀释得几乎看不见了（<1%）
- 绝对时间很小：0.13纳秒、24周期，这是什么概念？一秒钟可以调用几十亿次，除非你的函数调用频率真的达到这个量级，否则这点开销根本感受不到
什么时候该担心？
基于上面的分析，可以总结出一些简单的判断规则。
需要关注的场景：
- 函数体非常短小（getter/setter级别），调用开销占比较大
- 在热路径的紧密循环中被大量调用（百万次/秒级别）
- 调用目标频繁变化（不同派生类交替调用），导致分支预测器无法发挥作用
- 对延迟极度敏感的代码（游戏引擎的tick、音频处理的回调、高频交易系统的核心路径）
不需要担心的场景：
- 函数体本身就比较重（IO操作、复杂计算、网络请求），调用开销可以忽略
- 调用频率不高（每秒几千次以下），累计开销微乎其微
- 调用目标比较稳定（大部分时间调的是同一个派生类），分支预测器能很好地工作
- 不是性能关键路径，优化收益很小
说白了，如果你的函数调用本身就占程序运行时间的大头，而且函数体很短，那虚函数开销值得关注；否则，先用profiler看看再说，别瞎优化。
优化策略
如果profiler告诉你虚函数调用确实是瓶颈，有几个优化方向可以考虑。
1. 使用final关键字
如果你确定一个类不会再被继承，或者一个虚函数不会再被覆写，加上final关键字：
classDerivedfinal:publicBase{// 这个类不会再被继承public:voidfoo()final{/* ... */}// 这个函数不会再被覆写};编译器看到final，就知道不需要走虚函数那套流程了，可以直接内联或者静态调用，这叫去虚拟化（devirtualization），是一种几乎零成本的优化手段，加个关键字就能让编译器帮你做优化。
2. CRTP：静态多态
如果你需要的是编译期多态而不是运行时多态，可以用CRTP（Curiously Recurring Template Pattern）：
template<typenameDerived>classBase{public:voidinterface(){static_cast<Derived*>(this)->implementation();}};classMyClass:publicBase<MyClass>{public:voidimplementation(){/* ... */}};这种写法没有vtable，函数调用在编译期就确定了，可以被完美内联，性能和直接调用一样好。代价是失去了运行时多态的灵活性——你没法用一个Base*指针指向不同的派生类了，所以只适用于编译期就能确定类型的场景。
3. 批量处理同类型对象
与其混着调用不同类型的对象：
// 不好：类型频繁切换，分支预测器难受for(Base*obj:mixed_objects){obj->foo();}不如按类型分组处理：
// 好：同类型批量处理，分支预测器开心for(DerivedA*obj:a_objects){obj->foo();}for(DerivedB*obj:b_objects){obj->foo();}这样分支预测器可以在每个循环里稳定预测，大大减少预测失败的惩罚，对于需要处理大量多态对象的场景，这个优化往往效果显著。
4. 热路径避免虚函数
对于性能最敏感的那几个函数，考虑用模板或函数指针替代虚函数，在调用频率和灵活性之间找平衡。注意不要用std::function来"优化"性能——它内部使用类型擦除，调用开销通常不低于虚函数，有时甚至更高。不是所有地方都需要运行时多态，有时候编译期多态就够用了。
总结
虚函数调用确实比普通调用慢，开销主要来自四个方面：
- 内存访问：读vptr、读vtable，可能触发cache miss
- 间接分支：预测失败有惩罚，类型频繁切换时尤其明显
- 内联失效：丧失进一步优化机会，对短函数影响最大
- 缓存效应：频繁切换类型影响缓存命中率
但"慢"是相对的：对于短函数可能慢18%，对于长函数几乎没差别；一次调用多几十纳秒，调用百万次才能感受到。
虚函数是C++多态的基础，别因为"听说有性能开销"就不敢用。先写出正确、清晰的代码，等profiler告诉你虚函数调用是瓶颈，再考虑优化也不迟——过早优化是万恶之源。
