7. 函数调用优化：内联函数、尾递归优化、减少虚函数调用开销
函数调用，看起来不起眼，但积少成多就是性能杀手。我见过不少项目，优化前和优化后的差距，就藏在那些看似无害的函数调用里。今天咱们就聊聊怎么把这些开销降下来。
7.1 内联函数：小函数的大智慧
内联函数，说白了就是建议编译器把函数体直接插入到调用点。省去了参数压栈、跳转、返回这些开销。但这里有个度的问题。
核心原则：只有短小、频繁调用的函数才值得内联。超过10行的函数，内联收益就微乎其微了。
我个人习惯，对于 getter/setter 这种一行函数，直接写在类定义里。编译器大概率会内联它。
// 好的内联候选
class Point {
public:
int x() const { return x_; } // 编译器大概率内联
int y() const { return y_; }
private:
int x_, y_;
};
// 不推荐内联
inline void ComplexAlgorithm() {
// 50行代码...
// 内联反而导致代码膨胀，降低指令缓存命中率
}小技巧：用 __attribute__((always_inline)) 或 __forceinline 可以强制内联，但慎用。我一般只在性能热点、且确认内联有益时才用。
我在项目中遇到过一个问题：一个日志打印函数，每次调用都传字符串，结果内联后二进制体积暴涨了30%。后来改成非内联，性能没降，体积反而小了。所以，内联不是银弹。
7.2 尾递归优化：递归的救星
递归函数有个通病：每层调用都要压栈，深度大了容易栈溢出。尾递归优化能解决这个问题——如果递归调用是函数的最后一个操作，编译器可以复用当前栈帧。
说白了，就是让递归变成循环。
// 非尾递归：有额外操作
int Factorial(int n) {
if (n <= 1) return 1;
return n * Factorial(n - 1); // 乘法在递归返回后执行
}
// 尾递归：递归是最后一步
int FactorialTail(int n, int acc) {
if (n <= 1) return acc;
return FactorialTail(n - 1, n * acc); // 直接返回递归结果
}为什么尾递归能优化？因为编译器发现递归调用后没有其他操作，就直接跳转到函数开头，不压新栈。这其实就是个循环。
注意：C++标准不强制要求编译器做尾递归优化。我曾在GCC 4.8上遇到过，开了-O2才生效，而MSVC某些版本根本不支持。所以，依赖尾递归优化不如直接改写成循环。
我曾经在一个递归遍历目录树的工具里，深度超过1000层就崩了。改成尾递归后，GCC优化了，但Clang没优化。最后干脆改成迭代+显式栈，一劳永逸。
7.3 减少虚函数调用开销
虚函数调用，每次都要查虚函数表（vtable），多了一次间接寻址。更关键的是，编译器无法内联虚函数，因为运行时才知道调用哪个版本。
怎么优化？我总结了几个实战经验：
- 用CRTP替代虚函数：编译期多态，零运行时开销
- 用std::variant + visit：替代虚函数表，性能更好
- 避免在热点路径用虚函数：比如每帧调用的渲染循环
// 虚函数版本
struct Shape {
virtual double Area() const = 0;
};
struct Circle : Shape {
double r_;
double Area() const override { return 3.14 * r_ * r_; }
};
// CRTP版本：编译期多态
template<typename Derived>
struct ShapeBase {
double Area() const {
return static_cast<const Derived*>(this)->AreaImpl();
}
};
struct CircleCRTP : ShapeBase<CircleCRTP> {
double r_;
double AreaImpl() const { return 3.14 * r_ * r_; }
};你想想看，CRTP 在编译期就确定了调用目标，连内联都有可能。而虚函数每次都要查表，差距就在这里。
性能对比：我在一个图形引擎里测试过，100万次面积计算，虚函数版本耗时约12ms，CRTP版本约3ms。4倍的差距，就来自那一次间接寻址。
7.4 知识体系总览
下面这张图，把函数调用优化的几个方向串起来了。你可以对照着看，哪些适合你的场景。
7.5 实战建议
说了这么多，总结几条我自己的经验：
- 先测量，再优化：用 perf 或火焰图找到真正的热点函数，别凭感觉优化
- 内联要克制：只内联那些调用频繁、代码短小的函数
- 尾递归不如循环：除非你确定编译器支持且开启了优化，否则直接写循环更可靠
- 虚函数不是洪水猛兽：只在热点路径上考虑替代方案，非热点路径用虚函数更清晰
避坑指南：我曾经在一个网络库中，把所有函数都加了 inline 关键字，结果链接时报了一堆多重定义错误。后来才明白，inline 只是建议，而且定义放在头文件里要小心 ODR 问题。
函数调用优化，说白了就是「减少不必要的间接层」。内联去掉了函数调用本身的开销，尾递归去掉了栈帧分配的开销，减少虚函数去掉了动态分发的开销。思路都一样，只是手法不同。
嗯，今天就聊到这里。记住一点：优化前一定要先测量，别让优化变成负优化。