编译器优化：O1/O2/O3/Os优化级别、内联函数、循环展开、向量化（SIMD）

说到编译器优化，我脑子里第一个蹦出来的画面，是多年前一个深夜。

那时候我刚接手一个视频编解码项目，代码写得挺顺，一编译，跑起来卡成PPT。我盯着性能分析器，CPU占用率100%，但有效计算少得可怜。旁边老工程师路过，瞟了一眼屏幕，丢下一句话：「你开O2了吗？」

从那以后，我再也不敢小看编译器优化这几个字。

优化级别：O0、O1、O2、O3、Os

GCC和Clang都提供了一组优化级别开关。说白了，就是告诉编译器：「你帮我多动动脑子，还是少动脑子？」

级别	含义	典型场景
O0	不做优化，编译最快，调试信息最完整	开发调试阶段
O1	基础优化，减少代码体积和分支开销	嵌入式、对体积敏感的场景
O2	大部分优化开启，性能与编译时间平衡	日常发布版本，我90%的项目都用这个
O3	激进优化，包含向量化、函数内联等	计算密集型，比如音视频、科学计算
Os	以优化代码体积为目标	存储受限的嵌入式系统

我个人习惯是：开发阶段用O0，提测前切到O2。如果发现某个热点函数性能不够，再针对性地尝试O3或手动优化。

内联函数：省掉函数调用的开销

函数调用是有成本的——压栈、跳转、返回、弹栈。对于小函数，这个开销可能比函数体本身还大。

内联函数，就是告诉编译器：「把这个函数的代码直接贴到调用处，别跳来跳去了。」

// 传统写法
int add(int a, int b) {
    return a + b;
}

// 内联建议
inline int add(int a, int b) {
    return a + b;
}

什么时候该用内联？

• 函数体很小，比如两三行
• 被频繁调用，比如在循环内部
• 函数定义在头文件中（类成员函数默认inline）

什么时候别用？

• 函数体超过10行
• 函数有递归调用
• 函数有复杂的控制流（switch、大量分支）

循环展开：用空间换时间

循环展开，说白了就是把循环体复制几份，减少循环控制的开销。

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

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

你想想看，原始循环每次迭代都要做：i<8比较、i++自增、跳转回循环头。展开后，这些操作减少了一半。

不过，编译器在O2及以上级别会自动做循环展开。我一般不会手动写展开代码，除非遇到以下情况：

• 编译器没有自动展开（比如循环次数在运行时才能确定）
• 我需要配合SIMD做更精细的数据布局

向量化（SIMD）：让CPU一次处理多个数据

SIMD，全称Single Instruction Multiple Data。翻译成人话就是：一条指令，同时处理多个数据。

现代CPU都有SIMD指令集，比如x86的SSE、AVX，ARM的NEON。它们有128位、256位甚至512位的寄存器，可以一次塞进4个float或8个short。

// 普通加法
for (int i = 0; i < 1024; i++) {
    c[i] = a[i] + b[i];
}

// 用SIMD intrinsic手动向量化（SSE）
#include <xmmintrin.h>
for (int i = 0; i < 1024; i += 4) {
    __m128 va = _mm_loadu_ps(&a[i]);
    __m128 vb = _mm_loadu_ps(&b[i]);
    __m128 vc = _mm_add_ps(va, vb);
    _mm_storeu_ps(&c[i], vc);
}

编译器在O2和O3级别下，会自动尝试向量化循环。但自动向量化有很多限制：

• 循环次数必须是编译期可知的，或者至少是4的倍数
• 数据不能有依赖关系（比如a[i] = a[i-1] + 1就没法向量化）
• 内存访问要对齐

知识体系总览

下面这张图，是我梳理的编译器优化核心脉络。你可以把它当作一张「优化地图」：

综合建议

说了这么多，最后给你几条实在的建议：

1. 先开O2，再谈优化。很多性能问题，一个O2就解决了。别一上来就手写汇编。
2. 用性能分析器定位热点。别凭感觉优化。我见过太多人优化了不痛不痒的代码，真正慢的地方纹丝不动。
3. 内联函数用在刀刃上。小函数、高频调用、循环内部——这三个条件同时满足，才值得内联。
4. 循环展开交给编译器。除非你确认编译器没做好，或者你要配合SIMD。
5. SIMD是最后的杀手锏。手动向量化代码可读性差、移植性差，但性能提升也是最明显的。值得在核心算法上投入。