第18章库的优化技术

课程目录第18章库的优化技术

库的优化技术：LTO、PGO、内联展开与缓存友好设计

说实话，很多人觉得库写完了就完事了。链接一下，跑起来，能工作，就交差了。但在我眼里，这才刚走了一半的路。你想想看，一个库如果只是“能用”，那跟路边摊的快餐有什么区别？真正的好库，得是米其林级别的——不仅要功能对，还得性能好。

我这些年做底层优化，踩过的坑比写过的代码还多。今天就把几个压箱底的优化手段掏出来，跟你聊聊。

1. 链接时优化（LTO）

LTO 这玩意儿，说白了就是让编译器在链接阶段再做一次优化。你可能会问：“编译的时候不是已经优化过了吗？”嗯，这里有个误区。

传统的编译流程里，每个源文件是独立编译的。编译器只能看到当前文件的内容，看不到别的文件里有什么。这就导致了很多优化没法做——比如函数内联，如果函数定义在 A.c，调用在 B.c，那编译器就没办法把它内联进去。

LTO 解决了这个问题。它会把所有目标文件的信息都收集起来，在链接的时候统一分析、统一优化。

  核心收益：
  跨模块内联：函数可以跨文件内联
死代码消除：没用到的函数和数据会被彻底移除
更好的寄存器分配：编译器能看到全局的调用关系

我在一个嵌入式项目里用过 LTO。那是个资源受限的芯片，Flash 只有 256KB。开了 LTO 之后，代码体积直接缩小了 18%。我当时还挺惊讶的——因为之前手写的优化已经做得很极致了，没想到编译器还能再榨出这么多空间。

启用方式很简单，GCC 加个 -flto 就行：

# 编译时
gcc -c -flto -O2 file1.c file2.c

# 链接时
gcc -flto -O2 file1.o file2.o -o mylib.so

注意：LTO 会显著增加链接时间。我见过一个大型项目，链接时间从 30 秒飙到了 5 分钟。所以 CI 流程里要权衡一下，别让开发等太久。

2. 配置文件引导优化（PGO）

PGO 的思路很有意思。它分三步走：先用插桩版本跑一遍真实负载，收集运行时的数据，然后再用这些数据指导编译器做优化。

说白了，就是让编译器“偷看”你的程序到底是怎么跑的。哪些函数调用最频繁？哪些分支经常走？哪些循环迭代次数最多？这些信息，编译器自己猜不准，但 PGO 能拿到真实数据。

我做过一个网络协议栈的优化。没开 PGO 之前，吞吐量大概在 800Mbps。开了之后，直接飙到 1.2Gbps。为什么？因为编译器发现某个热点函数被频繁调用，就把它内联了，还做了更好的分支预测布局。

操作流程大概是这样：

# 第一步：生成插桩版本
gcc -fprofile-generate -O2 source.c -o mylib_prof

# 第二步：运行典型负载
./mylib_prof < typical_input.dat

# 第三步：使用 profile 数据重新编译
gcc -fprofile-use -O2 source.c -o mylib.so

我的建议：PGO 的效果高度依赖训练数据的代表性。如果你拿一个完全不同的场景去训练，优化效果可能适得其反。我曾经见过有人用单元测试做 PGO 训练，结果生产环境性能反而下降了——因为单元测试的代码路径跟真实流量完全不一样。

3. 内联与循环展开

内联，就是把函数调用直接替换成函数体。好处很明显：省去了调用开销，还能让编译器做更多的局部优化。但坏处也很直接：代码膨胀。

我个人的习惯是：小函数、高频调用的函数，优先内联。大函数或者很少调用的，就别内联了，省得把指令缓存撑爆。

GCC 里控制内联的方式：

// 强制内联
__attribute__((always_inline)) inline int add(int a, int b) {
    return a + b;
}

// 禁止内联
__attribute__((noinline)) int slow_func(int x) {
    // 复杂逻辑
}

循环展开则是把循环体复制多份，减少循环控制的开销。比如：

// 原始循环
for (int i = 0; i < 4; i++) {
    sum += arr[i];
}

// 展开后
sum += arr[0];
sum += arr[1];
sum += arr[2];
sum += arr[3];

编译器一般会自动做这个优化，但你可以用 pragma 控制：

#pragma GCC unroll 4
for (int i = 0; i < 1024; i++) {
    // ...
}

我曾经踩过的坑：有一次我把一个 1000 次的循环强制展开了 100 倍，结果代码体积暴涨，指令缓存命中率暴跌，性能反而下降了 30%。所以，展开不是越多越好，得看你的 CPU 的 L1I 缓存有多大。

4. 缓存友好设计

这是优化里最容易被忽视的一块。很多人只盯着算法复杂度，却忘了内存访问模式对性能的影响。

现代 CPU 的缓存层级大概是这样的：

缓存层级	典型大小	延迟（周期）
L1	32KB	3-4
L2	256KB	10-12
L3	8-32MB	30-40
主存	GB 级别	100+

看到没？L1 和主存的延迟差了 30 倍以上。所以，让数据尽量待在 L1 里，是优化的核心。

几个实用的原则：

空间局部性：访问内存时尽量连续。数组遍历比链表遍历快得多。
时间局部性：刚用过的数据，尽快再用。别跳来跳去。
结构体对齐：把热点成员放在结构体开头，减少缓存行浪费。

举个例子：

// 不友好的设计
struct Bad {
    int hot1;      // 频繁访问
    char padding[60]; // 填充
    int hot2;      // 频繁访问，但跟 hot1 不在同一个缓存行
};

// 友好的设计
struct Good {
    int hot1;      // 频繁访问
    int hot2;      // 紧挨着 hot1，大概率在同一个缓存行
    char padding[60]; // 不常用的放后面
};

我在做数据库引擎的时候，就靠这个技巧把索引扫描的性能提升了 40%。说白了，就是让热点数据挤在同一个缓存行里，别让 CPU 来回跑。

知识体系总览

下面这张图，把本章的核心逻辑串起来了：

这四个技术，其实对应了四个不同的优化维度。LTO 是让编译器看得更全，PGO 是让编译器知道得更准，内联展开是减少不必要的开销，缓存设计是让数据流动更高效。它们不是互斥的，而是可以叠加使用的。

我个人建议的优化顺序是：先做缓存友好设计（这是基础），再开 LTO（几乎零成本），然后针对热点做内联和展开，最后如果还有瓶颈，再上 PGO。别一上来就全开，否则你都不知道性能提升到底来自哪里。

一个小技巧：在性能调优时，每次只改一个变量。我见过太多人一次性改了十个地方，结果性能提升了，但根本不知道是哪个改动起了作用。下次遇到类似问题，还是得从头试一遍。

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

📚 课程目录

库的优化技术：LTO、PGO、内联展开与缓存友好设计

1. 链接时优化（LTO）

2. 配置文件引导优化（PGO）

3. 内联与循环展开

4. 缓存友好设计

知识体系总览