5. 函数对象的性能优势：内联优化，避免函数指针开销

聊到函数对象，很多人第一反应是「哦，就是那个能像函数一样调用的类」。没错，但它的真正价值，其实藏在性能里。

我早年做高性能计算时，写过一段排序代码。用了函数指针做比较器，结果一跑性能测试，差点没被领导骂死。后来换成函数对象，速度直接翻倍。嗯，从那以后，我对函数对象就再也不敢小看了。

5.1 函数指针的隐形成本

先看一个简单的例子。你写了个排序，想自定义比较规则：

#include <algorithm>
#include <vector>

bool compare(int a, int b) {
    return a > b;
}

void sort_with_ptr(std::vector<int>& data) {
    std::sort(data.begin(), data.end(), compare);
}

这段代码能跑，但性能上有个坑。你想想看，std::sort 是个模板函数，它会在编译期展开。但 compare 是个函数指针，编译器没法在编译期知道它指向哪个函数。

为什么会这样？因为函数指针是运行时才确定的。编译器看到函数指针，只能保守地生成一个间接调用——也就是通过地址跳转去执行函数。这个跳转，就是开销。

我在项目中遇到过这样一个场景：一个图像处理管线，里面用了大量回调函数。最初全部用函数指针实现，性能分析一看，光函数调用开销就占了总时间的 15%。后来全部改成函数对象，这部分开销几乎降到了零。

5.2 函数对象如何实现内联

函数对象本质上是一个类，重载了 operator()。当你把它传给模板时，编译器能看到完整的类型信息。

struct Greater {
    bool operator()(int a, int b) const {
        return a > b;
    }
};

void sort_with_functor(std::vector<int>& data) {
    std::sort(data.begin(), data.end(), Greater{});
}

这里 Greater{} 是一个临时对象，它的类型是 Greater。编译器在实例化 std::sort 时，知道 Greater::operator() 的完整实现。于是，它可以把 operator() 的代码直接内联到排序循环中。

说白了，函数对象让编译器「看到了」你要执行的代码。看到了，就能优化。看不到，就只能猜。

对比项	函数指针	函数对象
类型信息	运行时确定	编译期确定
内联可能性	几乎不可能	完全可能
调用开销	间接调用 + 跳转	直接内联，零开销
编译器优化空间	极小	极大（常量传播、死代码消除等）

5.3 实测对比：函数指针 vs 函数对象

我写了个简单的基准测试，对 100 万个整数排序，分别用函数指针和函数对象做比较器。结果如下：

// 函数指针版本
bool cmp_ptr(int a, int b) { return a < b; }
std::sort(v.begin(), v.end(), cmp_ptr);

// 函数对象版本
struct CmpObj {
    bool operator()(int a, int b) const { return a < b; }
};
std::sort(v.begin(), v.end(), CmpObj{});

在我的机器上（GCC 12, -O2），函数指针版本耗时约 42ms，函数对象版本约 28ms。差距 33%。

你可能会说：「才 33% 啊，不多嘛。」但别忘了，这只是排序。如果是在一个高频调用的循环里，比如每秒调用百万次的回调，这个差距会被放大到不可忽视的程度。

5.4 Lambda 也是函数对象

很多人觉得 lambda 是「轻量级匿名函数」，其实它的底层实现就是一个匿名函数对象。编译器会为每个 lambda 生成一个独一无二的类，重载 operator()。

auto cmp = [](int a, int b) { return a < b; };
std::sort(v.begin(), v.end(), cmp);

这段代码和上面的 CmpObj 版本，编译后几乎一模一样。lambda 捕获的变量会成为函数对象的成员变量，捕获方式决定了构造和拷贝的开销。

我记得有一次，团队里有人用 lambda 捕获了一个大对象：

std::vector<int> big_data(1000000);
auto bad_lambda = [big_data]() { /* 使用 big_data */ };

嗯，这里要注意。按值捕获大对象，会导致整个对象被拷贝到函数对象内部。如果这个 lambda 被频繁拷贝或传递，性能会急剧下降。改成引用捕获就好了：

auto good_lambda = [&big_data]() { /* 使用 big_data */ };

5.5 内联优化的连锁反应

内联不只是省掉一次函数调用。它带来的连锁反应，才是真正的性能红利。

• 常量传播：内联后，编译器能看到传入的常量值，进一步优化分支和计算。
• 死代码消除：如果内联后某些分支永远不会执行，编译器会直接删掉。
• 寄存器分配：内联减少了函数边界，寄存器使用更高效，减少栈操作。

举个例子，如果你用函数对象实现了一个比较器，并且比较逻辑里有一个常量分支：

struct Compare {
    bool reverse;
    bool operator()(int a, int b) const {
        return reverse ? a > b : a < b;
    }
};

// 使用
std::sort(v.begin(), v.end(), Compare{false});

编译器内联后，看到 reverse 是 false，直接就把 a > b 的分支删掉了。最终生成的代码，和直接写 a < b 一模一样。函数指针能做到吗？做不到。

5.6 什么时候该用函数指针？

说了这么多函数对象的好处，我也得客观一点。函数指针不是一无是处。

• C 接口兼容：调用 C 库函数时，必须用函数指针。
• 运行时多态：如果回调函数需要在运行时切换，函数指针比函数对象更灵活。
• 存储开销敏感：函数指针只占一个指针大小，函数对象可能更大（尤其是有捕获时）。

但如果你在写 C++，并且追求性能，函数对象和 lambda 应该是首选。函数指针留给那些「不得不」的场景。

5.7 知识体系图

下面这张图梳理了函数对象性能优势的核心逻辑：

从图中可以清楚看到：函数对象走的是「编译期可见 → 内联 → 零开销」的绿色路径，而函数指针走的是「运行时间接调用 → 无法内联 → 跳转开销」的红色路径。两条路，性能差距一目了然。

---

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