代码优化策略：编译器优化选项、内联与链接时优化、循环展开与优化、PGO优化

说到代码优化，很多人第一反应是「我手写汇编肯定比编译器强」。嗯，我年轻时也这么想。直到有一次，我花了一周手写的SIMD向量化代码，被编译器-O2一跑，性能只差了5%。那一刻我明白了——现代编译器，真的不傻。

但话说回来，编译器也不是万能的。你得学会跟它「对话」。告诉它你的意图，给它足够的上下文，它才能帮你把代码榨干。今天我们就聊聊这四块：编译器优化选项、内联与LTO、循环展开、PGO。

1. 编译器优化选项：别只会用-O2

很多同学写Makefile，优化选项万年不变就是-O2。其实不同场景，适合的优化等级完全不同。

选项	作用	编译时间	适用场景
-O0	不做优化，调试友好	快	开发调试阶段
-O1	基础优化，减少代码体积	较快	嵌入式、内存受限场景
-O2	大多数优化开启，平衡之选	中等	日常发布
-O3	激进优化，包括向量化	较慢	计算密集型、数值计算
-Ofast	无视标准合规，极致性能	较慢	科学计算、游戏（慎用）

我个人习惯是：开发用-O0 -g，CI测试用-O2，正式发布前用-O3跑一遍性能测试。但要注意，-O3并不总是更快。我在项目中遇到过，-O3把一段循环自动向量化后，反而因为数据对齐问题导致性能下降。所以，一定要实测。

2. 内联与链接时优化（LTO）

内联，说白了就是把函数调用直接替换成函数体。好处是省去了调用开销，坏处是代码膨胀，可能把指令缓存撑爆。

我见过有人把几百行的函数都加上inline关键字，结果性能反而变差了。为什么？因为指令缓存被撑爆了，CPU频繁去内存取指令，比函数调用还慢。

正确的做法是：让编译器自己决定。用-finline-functions（GCC）或/Ob2（MSVC），编译器会根据函数大小、调用频率自动判断。

但这里有个坑——跨编译单元的内联。比如你在a.cpp里定义了一个函数，在b.cpp里调用它。没有LTO时，编译器看不到b.cpp的调用上下文，没法内联。

LTO（Link Time Optimization）就是来解决这个问题的。它把优化推迟到链接阶段，让编译器看到整个程序的全貌。

# 编译时生成中间表示
g++ -flto -c a.cpp -o a.o
g++ -flto -c b.cpp -o b.o

# 链接时做全局优化
g++ -flto a.o b.o -o program

3. 循环展开与优化

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

// 原始循环
for (int i = 0; i < 100; i += 1) {
    a[i] = b[i] + c[i];
}

// 手动展开4次
for (int i = 0; i < 100; i += 4) {
    a[i]   = b[i]   + c[i];
    a[i+1] = b[i+1] + c[i+1];
    a[i+2] = b[i+2] + c[i+2];
    a[i+3] = b[i+3] + c[i+3];
}

手动展开的好处是，你可以控制展开因子，配合SIMD指令。但说实话，现代编译器在-O2以上会自动做循环展开。你手动展开反而可能干扰编译器的优化。

我曾经在一个图像处理项目里，手动展开了所有循环。结果编译器报了一堆警告，说「检测到可疑的循环展开，已忽略」。嗯，白忙活了。

更好的做法是用#pragma告诉编译器你的意图：

#pragma GCC unroll 4
for (int i = 0; i < n; i++) {
    a[i] = b[i] * c[i];
}

这样既保留了代码可读性，又给了编译器提示。两全其美。

4. PGO优化：让数据说话

PGO（Profile-Guided Optimization）是我个人觉得最被低估的优化手段。它分三步走：

1. 插桩编译：用-fprofile-generate编译，生成带性能监控的可执行文件
2. 运行训练：用典型数据跑一遍，生成profile文件
3. 反馈优化：用-fprofile-use重新编译，编译器根据profile做优化

# 第一步：插桩编译
g++ -O2 -fprofile-generate main.cpp -o program

# 第二步：运行训练（用典型数据）
./program < training_data.txt

# 第三步：反馈优化
g++ -O2 -fprofile-use main.cpp -o program_final

PGO能做什么？它能告诉编译器：

• 哪些分支更常走（优化分支预测）
• 哪些函数是热点（更激进地内联）
• 哪些循环执行次数多（调整展开因子）

我在一个数据库引擎项目里用过PGO，性能提升了15%。而且代码一行没改，只是重新编译了一次。这种「白捡」的性能优化，谁不爱呢？

知识体系总览

下面这张图，帮你理清这四种优化策略的关系和适用场景：

你看，这四种策略不是孤立的。编译器选项是基础，LTO解决跨模块问题，循环展开是微观调优，PGO则是用数据驱动优化。我建议的实践顺序是：先用-O2 + LTO打底，再用PGO做第二轮优化，最后针对热点循环手动调优。

记住一句话：不要跟编译器较劲，要跟它合作。你给它足够的上下文和正确的指令，它就能还你一个性能惊喜。

---

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