18、函数与性能优化：函数调用的开销，尾调用优化，编译器优化选项对函数的影响

说到函数，很多嵌入式工程师第一反应是「封装」和「复用」。这没错。但很少有人会去想——调用一个函数，到底要付出多少代价？

我早年做电机控制时，就吃过这个亏。一个中断服务程序里调了七八个函数，结果波形抖得跟心电图似的。后来一查，全是函数调用开销惹的祸。今天我们就来把这笔账算清楚。

18.1 函数调用的隐藏成本

你写一句 foo(a, b)，编译器在背后干了多少事？

• 保存现场：把当前函数的寄存器压栈（R0-R12、LR、PC 等）
• 参数传递：通过寄存器或栈传递实参
• 跳转执行：修改 PC 指针，跳转到被调函数入口
• 返回恢复：从栈中恢复现场，跳回原函数

我曾在 Cortex-M4 上实测过：一个空函数调用，大约消耗 12~16 个 CPU 周期。如果函数体本身只有 3 条指令，那调用开销占比就超过 80%。

18.2 尾调用优化：编译器帮你「偷懒」

什么叫尾调用？就是函数最后一条语句是调用另一个函数，并且直接返回它的结果。

// 尾调用示例
int add(int a, int b) {
    return a + b;
}

int calc(int x, int y) {
    return add(x, y);  // 尾调用
}

为什么这个模式特殊？因为 calc 调用 add 之后，自己就没事干了。那何必还保留 calc 的栈帧？

尾调用优化（TCO） 就是干这个的：编译器直接复用当前栈帧，跳转到被调函数，省掉 push/pop 的开销。

但要注意：C 标准不强制要求编译器做 TCO。GCC 在 -O2 及以上会做，但有些编译器（比如某些 IAR 版本）默认不做。你得查手册确认。

18.3 编译器优化选项：从 -O0 到 -Os

同一个函数，不同优化级别下，生成的汇编代码天差地别。我习惯用一张表来对比：

优化级别	特点	函数调用处理方式	适用场景
-O0	无优化，调试友好	完整调用流程，不内联	开发调试阶段
-O1	基础优化	部分内联，减少栈操作	一般产品代码
-O2	较强优化	积极内联，尾调用优化	性能敏感代码
-O3	激进优化	强制内联，循环展开	计算密集型
-Os	优化代码大小	减少内联，复用代码段	Flash 受限的 MCU

举个例子。一个简单的加法函数：

int square(int x) {
    return x * x;
}

int main() {
    int a = square(5);
    return a;
}

在 -O0 下，square 会被完整调用——压栈、跳转、返回。在 -O2 下，编译器直接把它内联成 int a = 25;，连函数调用都没了。

18.4 内联函数：手动 vs 自动

inline 关键字只是给编译器的「建议」，不是命令。编译器有权忽略它。

我个人的做法是：

• 函数体 ≤ 3 行，且被高频调用 → 用 static inline
• 函数体 4~10 行 → 交给编译器自动决定（开 -O2）
• 函数体 > 10 行 → 不内联，避免代码膨胀

为什么？内联虽然省了调用开销，但会复制代码。如果一个函数被调用 100 次，内联后代码体积膨胀 100 倍。在 Flash 只有 64KB 的 MCU 上，这可能是灾难。

18.5 函数调用的性能优化策略

总结一下我这些年积累的几条原则：

1. 高频路径少调用：中断、循环内部，尽量把函数体直接展开或用宏替代
2. 善用尾递归：递归深度大时，确保编译器支持 TCO
3. 合理选择优化级别：不要无脑 -O3，代码膨胀可能反而拖慢速度
4. 用 profile 说话：别猜，用示波器或 profiler 看实际开销
5. 注意 ABI 差异：不同架构的参数传递规则不同，ARM 和 x86 的调用开销差很多

18.6 函数调用开销与优化决策流程图

下面这张图是我自己梳理的决策流程，帮你快速判断要不要优化某个函数调用：

这张图的核心逻辑很简单：先看频率，再看大小，最后看调用形式。别一上来就想着优化，先问自己——这个函数真的被频繁调用吗？

---

公众号：蓝海资料掘金营，微信 deep3321