20. 编译时优化：常量折叠、死代码消除、内联展开、模板元编程

聊到编译时优化，我得先跟你掏心窝子说一句：很多性能问题，其实在编译阶段就能解决大半。你写代码时觉得“这地方会不会慢”，编译器往往比你想得更聪明。但前提是——你得知道它到底在做什么，才能写出让它发挥到极致的好代码。

今天咱们就掰开揉碎，把编译时优化的四个核心手段讲透：常量折叠、死代码消除、内联展开、模板元编程。这四兄弟，说白了就是编译器帮你“提前算好”、“扔掉垃圾”、“省去调用开销”、“把运行时的活搬到编译时干”。

20.1 常量折叠：编译器替你算好了

什么叫常量折叠？举个例子：

int x = 3 + 5 * 2;
// 编译器直接变成 int x = 13;

就这么简单。编译器在编译阶段就把表达式算完了，运行时直接拿结果。你想想看，如果这段代码在一个循环里被调用几百万次，每次都要重新算一遍 3+5*2，那得多冤？

我在项目中遇到过一种情况：有人写了一大堆宏定义，里面全是常量运算，结果生成的代码里这些运算还在运行时重复计算。其实只要打开 -O2 优化，编译器自动就帮你折叠了。但如果你写的是这样的代码：

#define BASE_ADDR 0x4000
#define OFFSET 0x100
uint32_t reg = BASE_ADDR + OFFSET * 2;  // 编译时直接变成 0x4200

嗯，这里要注意：常量折叠只对编译期能确定的值有效。如果你用了 volatile 变量、函数调用返回值，那编译器就没办法了。

20.2 死代码消除：别让垃圾代码拖累你

死代码消除，说白了就是编译器帮你“扔垃圾”。那些永远不会被执行到的代码，或者计算结果永远不会被使用的变量，编译器会直接删掉。

int func(int x) {
    int a = x * 2;
    if (false) {
        return 100;  // 死代码，永远不会执行
    }
    return a;
}
// 优化后：int func(int x) { return x * 2; }

我曾经在一个嵌入式项目里，看到有人为了调试方便，在 release 版本里留了一大堆 #if 0 包裹的代码。结果编译器虽然不会生成这些代码，但代码可读性极差。更糟糕的是，有些人用 if(0) 而不是 #if 0，编译器虽然能消除，但会留下分支预测的痕迹——虽然现代编译器基本都能处理，但何必呢？

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

函数调用是有代价的：压栈、跳转、返回、弹栈。对于小函数来说，这个开销可能比函数体本身的执行时间还长。内联展开就是编译器把函数调用直接替换成函数体代码，省掉这些开销。

// 原始代码
inline int add(int a, int b) {
    return a + b;
}
int result = add(3, 4);

// 内联展开后
int result = 3 + 4;  // 进一步常量折叠成 int result = 7;

但这里有个坑：内联不是免费的。如果函数体很大，或者被调用了很多次，内联会导致代码膨胀，反而影响指令缓存的命中率。我见过有人把整个业务逻辑写在一个 inline 函数里，结果编译出来的二进制体积暴涨，性能反而下降了。

我个人习惯是：只有 3-5 行的小函数才考虑内联。而且现在编译器比你聪明，你写 inline 它不一定听，你不写它也可能自动内联。所以，别太纠结于 inline 关键字，把精力放在代码逻辑上。

20.4 模板元编程：把运行时的活搬到编译时

模板元编程（TMP）是 C++ 独有的黑科技。说白了，就是利用模板的实例化机制，在编译期完成计算。最经典的例子是编译期计算阶乘：

template <int N>
struct Factorial {
    static const int value = N * Factorial<N-1>::value;
};

template <>
struct Factorial<0> {
    static const int value = 1;
};

// 使用：Factorial<5>::value 在编译时就是 120

你想想看，如果这个阶乘是在运行时用循环算的，每次调用都要执行 N 次乘法。但用模板元编程，编译器直接帮你算好，运行时就是一个常量。我在做图像处理算法时，经常用模板元编程来展开循环、计算查表索引，效果立竿见影。

但说实话，模板元编程的代码可读性很差。我建议你只在性能关键路径上使用，而且一定要写清楚注释。否则三个月后你自己都看不懂写了啥。

template <typename T>
auto get_value(T t) {
    if constexpr (std::is_integral_v<T>) {
        return t + 1;
    } else {
        return t;
    }
}

20.5 知识体系总览

下面这张图，我把这四个优化手段的关系和适用场景画出来了。你看一眼就能明白它们各自的位置：

20.6 实际项目中的组合拳

在实际项目中，这四个优化手段经常一起出现。我给你说个真实案例：

我之前优化一个视频编码器里的量化模块，里面有个查表操作：

// 原始代码
int quantize(int value, int qp) {
    static const int table[16] = {1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096, 8192, 16384, 32768};
    return value / table[qp];
}

这个函数被调用了上亿次。我做了三件事：

1. 把 table 改成 constexpr，让编译器在编译期就确定数组内容
2. 把函数声明为 inline，消除调用开销
3. 用模板元编程生成查表索引，让 qp 在编译期就确定

最终版本：

template <int QP>
inline int quantize(int value) {
    static_assert(QP >= 0 && QP < 16, "QP out of range");
    constexpr int divisor = 1 << QP;  // 常量折叠
    return value / divisor;
}

性能提升了大约 30%。为什么？因为编译器把除法优化成了移位操作，而且函数调用完全被消除了。

嗯，今天就聊到这儿。这些技巧你可以在自己的项目里试试，尤其是那些被频繁调用的热点代码。你会发现，有时候改几行代码，性能提升比换算法还明显。