4. 指针与引用的性能影响

指针和引用，是C/C++里最让人又爱又恨的东西。爱它，是因为灵活、高效；恨它，是因为稍不留神就踩坑。今天咱们就聊聊指针和引用背后的性能账。

我刚开始做嵌入式开发那会儿，总觉得指针就是个地址，解引用不就是读个内存嘛，能有多大开销？后来被现实狠狠教育了一回——一个简单的链表遍历，因为指针别名问题，编译器死活不肯优化，性能直接掉了30%。嗯，从那以后我再也不敢小看指针了。

4.1 指针解引用的开销

先说说最基础的问题：指针解引用到底有多贵？

说白了，解引用就是一次内存访问。如果指针指向的数据在L1缓存里，那开销几乎可以忽略不计——大概1-2个CPU周期。但如果数据在L2、L3甚至主存里呢？

存储层级	典型延迟	相对代价
L1缓存	~1-2 周期	几乎免费
L2缓存	~10-20 周期	有点疼
L3缓存	~30-50 周期	开始肉疼
主存	~100-300 周期	灾难级别

你想想看，一个简单的p->x操作，如果缓存没命中，CPU可能要等上百个周期。这期间它在干嘛？干等。这就是所谓的“内存墙”。

我在项目中遇到过这样一个场景：一个深度优先的树遍历，每次递归都要解引用好几个指针。后来我把树节点重新排列成数组，用索引代替指针，性能提升了将近一倍。为什么？因为数组是连续内存，缓存友好。

4.2 指针别名问题与restrict关键字

这个坑，我估计很多老手都踩过。指针别名（pointer aliasing）指的是两个或多个指针指向同一块内存区域。编译器看到这种情况，会变得非常“保守”。

举个例子：

void add(int *a, int *b, int *c, int n) {
    for (int i = 0; i < n; i++) {
        a[i] = b[i] + c[i];
    }
}

这段代码看起来没问题对吧？但编译器心里会犯嘀咕：a和b会不会指向同一个数组？如果会，那每次写a[i]都可能影响后面读b[i+1]的结果。于是，编译器不敢用SIMD指令，不敢循环展开，甚至不敢把b[i]提前加载到寄存器里。

这就是别名问题的代价——编译器被迫生成保守的、低效的代码。

加上restrict之后：

void add(int *restrict a, int *restrict b, int *restrict c, int n) {
    for (int i = 0; i < n; i++) {
        a[i] = b[i] + c[i];
    }
}

编译器看到restrict，就知道a、b、c三者不会重叠。于是它可以放心大胆地做优化：向量化、循环展开、预取……性能提升20%-50%是很常见的。

我曾经在一个图像处理库中，给所有指针参数加上restrict，整个库的性能提升了40%。当然，前提是你得确保真的没有别名——否则就是未定义行为，程序可能崩溃。

4.3 函数指针与虚函数表的性能代价

函数指针和虚函数，本质上都是间接调用。间接调用比直接调用慢，这是肯定的。但到底慢多少？

直接调用：编译器在编译时就知道目标地址，可以预测分支，甚至可以内联。

间接调用：运行时才知道目标地址，分支预测器很难猜对，而且不能内联。

我做过一个测试：

// 直接调用
void direct_call() {
    for (int i = 0; i < 100000000; i++) {
        func();  // 直接调用
    }
}

// 函数指针调用
void fp_call(void (*fp)()) {
    for (int i = 0; i < 100000000; i++) {
        fp();  // 间接调用
    }
}

在我的机器上，直接调用版本耗时约0.3秒，函数指针版本耗时约1.2秒。差了4倍！

为什么会这样？两个原因：

• 分支预测失败：间接调用的目标地址是变化的，CPU的分支预测器很难准确预测，一旦预测失败，就要清空流水线，损失十几个周期。
• 无法内联：编译器不知道最终调用的是哪个函数，所以不能做内联优化。内联不仅能省去调用开销，还能让后续的优化（如常量传播）成为可能。

虚函数的代价和函数指针类似，但多了一层间接性——先查虚函数表，再取函数地址，然后调用。所以虚函数比普通函数指针还要慢一点点。

调用方式	相对开销	能否内联
直接调用	1x	可以
函数指针	~3-5x	不能
虚函数	~4-6x	不能

当然，这并不意味着你要完全避免函数指针和虚函数。它们带来的灵活性是直接调用无法替代的。我的建议是：

• 在热点路径（hot path）上，尽量用直接调用
• 如果必须用虚函数，考虑用模板或CRTP模式来消除虚函数开销
• 函数指针适合回调场景，但别在循环内部频繁调用

4.4 本章知识体系

下面这张图，帮你理清指针与引用性能影响的核心脉络：

总结一下今天的内容：指针解引用的开销主要来自缓存未命中，别名问题让编译器束手束脚，间接调用则因为分支预测和内联限制而变慢。理解了这些，你就能写出既灵活又高效的代码。

可可精品资料库