16、编译优化：O0/O1/O2/O3/Os等级，常见优化技术

说到编译优化，我估计不少同学第一反应就是「开O2就完事了」。嗯，我以前也这么干过。直到有一次在嵌入式项目里，开了O2优化后程序跑飞了，我才老老实实把每个优化等级都研究了一遍。

说白了，编译优化就是编译器帮你「偷懒」——在不改变程序语义的前提下，让代码跑得更快、占得更少。但编译器不是万能的，有时候它「偷懒」的方式会坑到你。

16.1 优化等级：从O0到O3

GCC和Clang都支持这几个等级。我列个表，你一看就明白：

等级	含义	典型场景
O0	无优化	调试阶段，保证每行代码都能对应到源码
O1	轻度优化	快速编译，兼顾调试和性能
O2	中度优化	日常发布，大多数项目的默认选择
O3	重度优化	计算密集型，愿意用体积换速度
Os	体积优化	嵌入式、固件，代码空间受限

16.2 各等级到底开了什么？

我习惯用GCC的 -Q --help=optimizers 来查看具体开了哪些选项。这里挑几个关键的说：

O0

啥都不干。变量全在内存里，循环老老实实跑。调试体验最好，但性能最差。

O1

开启 -fauto-inc-dec、-fbranch-count-reg 等基础优化。我印象最深的是它会做「常量传播」——比如 int a = 5; int b = a + 3; 直接变成 int b = 8;。

O2

这是我最常用的等级。它包含了O1的所有优化，还加了 -finline-small-functions、-fpeephole2 等。说白了，O2在「编译时间」和「运行速度」之间找到了平衡点。

O3

O3比O2多了 -finline-functions、-funswitch-loops 等激进优化。我曾经在一个图像处理项目里试过O3，速度确实快了15%，但代码体积膨胀了30%。

Os

这个等级很有意思。它优先减小体积，而不是提升速度。比如它会用更短的指令序列，哪怕多执行几条。我在做IoT设备固件时经常用Os，毕竟Flash空间就那么点。

16.3 常见优化技术详解

下面这几个优化技术，是编译器最常用的手段。我一个个说：

16.3.1 内联（Inlining）

内联就是把函数调用直接替换成函数体。比如：

// 原始代码
static int add(int x, int y) {
    return x + y;
}

int result = add(3, 4);

// 内联后
int result = 3 + 4;  // 省去了函数调用开销

内联的好处是省去了压栈、跳转、返回的开销。但坏处是代码体积变大。编译器一般只内联小函数，或者用 inline 关键字提示。

16.3.2 循环展开（Loop Unrolling）

循环展开就是减少循环次数，把多次迭代合并成一次。看个例子：

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

// 展开后
arr[0] = 0;
arr[1] = 2;
arr[2] = 4;
arr[3] = 6;

展开后减少了循环控制指令（i++、比较、跳转），但代码变长了。编译器一般只展开小循环，或者用 #pragma unroll 强制展开。

为什么会这样？因为现代CPU有指令流水线，循环控制指令会打断流水线。展开后流水线更顺畅，性能就上去了。

16.3.3 常量传播（Constant Propagation）

这个优化很简单：如果编译器能确定某个变量的值，就直接用常量替换。比如：

int x = 10;
int y = x * 2;   // 编译器直接算出 y = 20
int z = y + 5;   // 进一步算出 z = 25

常量传播经常和「常量折叠」一起用。折叠就是把常量表达式直接算出来，比如 3 + 4 * 2 直接变成 11。

16.4 优化等级的选择策略

我个人建议这样选：

• 开发调试阶段：用O0。别开优化，不然断点可能跳不到正确位置。
• 单元测试：用O1。既能发现一些优化带来的bug，又不会太慢。
• 正式发布：用O2。这是最稳妥的选择。
• 性能敏感模块：可以试试O3，但一定要做性能对比测试。
• 嵌入式/固件：用Os。代码体积小，省Flash空间。

16.5 知识体系总览

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

16.6 实际项目中的选择

最后分享一个我自己的经验。在做嵌入式Linux项目时，我一般这样配置：

• 内核模块：用O2。内核本身对优化很敏感，O2最稳定。
• 用户态应用：用O2。如果性能不够，再针对热点函数用O3。
• 启动代码：用Os。启动阶段代码越小，加载越快。
• 调试版本：用O0。配合 -g 选项，调试体验最好。

嗯，编译优化这东西，说白了就是「用编译时间换运行时间」。你想想看，编译器多花几秒钟分析代码，你的程序就能快几毫秒，这笔账怎么算都划算。但前提是——你得知道编译器到底做了什么，不然被坑了都不知道。

---