27. 性能调优：Lambda 的编译期展开与内联，避免 std::function 开销

聊到 Lambda 的性能，我得先跟你交个底：Lambda 本身是零开销的。你写一个 Lambda，编译器在背后生成一个匿名类，重载了 operator()。这个过程没有运行时成本，没有虚函数，没有动态内存分配。说白了，Lambda 就是一块语法糖，甜得很。

但问题出在哪儿呢？出在你怎么用这个 Lambda。

Lambda 的编译期展开：编译器到底在干嘛？

我举个例子。你写了个 Lambda 传给 std::sort：

std::vector<int> v = {3, 1, 4, 1, 5, 9};
std::sort(v.begin(), v.end(), [](int a, int b) { return a < b; });

编译器看到这段代码，会生成一个类似这样的类：

class __lambda_1 {
public:
    inline bool operator()(int a, int b) const { return a < b; }
};

然后 std::sort 被实例化成 std::sort<..., __lambda_1>。因为 Lambda 的类型是唯一的，编译器知道 operator() 的具体实现。于是它就可以做一件事——内联展开。

内联展开意味着什么？意味着 std::sort 内部的比较操作，直接变成了 a < b 这条指令，没有函数调用开销，没有跳转，没有栈帧的压栈弹栈。我在项目中做过测试，同样的排序任务，用 Lambda 比用函数指针快了将近 30%。原因就在这儿。

std::function 的代价：为什么它这么慢？

好，现在换个写法：

std::function<bool(int, int)> comp = [](int a, int b) { return a < b; };
std::sort(v.begin(), v.end(), comp);

这段代码也能跑，但性能就差远了。为什么？

std::function 是一个类型擦除的包装器。它内部用了小对象优化（SBO）和虚函数（或者等效的间接调用）。当你调用 comp(a, b) 时，实际流程是：

1. 通过函数指针或虚函数表跳转到内部存储的调用包装器。
2. 包装器再调用你真正的 Lambda。
3. 如果 Lambda 捕获了变量，还可能涉及动态内存分配。

每一步都是开销。更致命的是，编译器无法内联这个调用链。因为 std::function 的类型擦除把具体类型信息藏起来了，编译器看不到 Lambda 的内部实现。

我曾经在一个实时音频处理项目里踩过这个坑。音频缓冲区每秒钟要处理 44100 次回调，我一开始图方便用了 std::function 来传递处理逻辑。结果 CPU 占用率直接飙到 80%，换成模板参数后降到了 15%。嗯，这个教训我记得很清楚。

什么时候该用 std::function？

那 std::function 就一无是处吗？也不是。它有自己的用武之地：

场景	推荐方案	原因
回调注册、事件系统	std::function	类型擦除方便，存储异构可调用对象
热路径（循环、排序、算法）	模板参数或 auto	编译器可以内联展开
跨 ABI 边界（动态库接口）	std::function 或函数指针	模板无法跨 ABI
需要存储可调用对象到容器	std::function	类型擦除后可以统一存储

说白了，std::function 是灵活性换性能的典型代表。你用它的时候，心里要清楚：我是在为灵活性买单。

如何避免 std::function 开销？

我总结了三条实用建议：

1. 用模板参数代替 std::function

// 不推荐
void process(std::function<void(int)> fn);

// 推荐
template<typename F>
void process(F fn);

模板参数保留了具体类型，编译器可以尽情内联。代价是代码膨胀？其实没那么严重，现代链接器会做去重。

2. 用 auto 参数（C++20）

void process(auto fn) {
    fn(42);
}

C++20 的 auto 参数本质上是模板的语法糖，效果一样。

3. 用函数指针——但小心

无捕获的 Lambda 可以隐式转换为函数指针：

void (*fp)(int) = [](int x) { std::cout << x; };
fp(42);

函数指针的调用开销比 std::function 小得多，但编译器仍然无法内联（除非你用了 constexpr 或链接时优化）。所以它只是比 std::function 好，但不如模板参数。

SVG 流程图：Lambda 调用路径对比

下面这张图展示了 Lambda 直接调用、通过模板参数调用、以及通过 std::function 调用的路径差异。你可以直观地看到为什么 std::function 慢。

总结

Lambda 本身是零开销的，但你怎么用它决定了最终的性能。记住三条原则：

• 热路径用模板参数或 auto，让编译器尽情内联。
• std::function 只用在需要类型擦除的地方，比如回调注册、事件系统。
• 无捕获的 Lambda 更友好，对 std::function 的小对象优化有利。

我个人习惯在写库接口时，优先用模板参数。只有在必须存储可调用对象到容器、或者跨 ABI 边界时，才退而求其次用 std::function。你想想看，既然编译器给了我们免费的内联能力，干嘛不接着呢？