徐术挺-漫思录

17-零成本抽象与性能

22分钟阅读

第十七章 零成本抽象与性能：你不为没用的东西付钱

你有没有被人安利过”高级抽象”——泛型、迭代器、trait 对象——然后心里犯嘀咕：这玩意儿写起来是爽，可运行时是不是偷偷给我加了层层间接、搞出一堆虚函数调用、把我精心优化的性能全吃了？如果 Rust 也这样，那它所谓的”系统级语言”岂不是空话？

我是墨叔，机房里泡了二十年。性能敏感的程序员对”抽象”天然警惕，这警惕没错——在不少语言里，抽象确实是有税的：你每用一次漂亮的语法糖，运行时就默默多付一次代价。但 Rust 有一句被反复引用的口号，是 Bjarne Stroustrup（C++ 之父）那句名言的直系血亲：“你不为没使用的抽象付代价；你使用的抽象，不会带来比手写等价代码更差的性能。” 这一章，我们把这句漂亮话拆成能落地的机理。

先给结论：零成本抽象（zero-cost abstraction）不是”抽象免费”，而是”抽象在最终机器码里被消去了”——你写的优雅代码，编译后和优化手写、贴着硬件写的代码别无二致，而你看不到的那层抽象，在编译期就被摊平了。

一、“零成本”到底在说什么，又在没说什么

先纠正一个常见误会：零成本不是”任何抽象都没有运行时开销”。它说的是两条，缺一不可：

第一条，你不为没用到的东西付钱。你在一个 crate 里引入了某个很重的 trait、某个泛型结构，但你的二进制里实际没实例化它，那它的代码根本不会进你的可执行文件。不像有些语言，引个库就把整座运行时搬进来。

第二条，你用到的抽象，在优化后等价于手写。关键在”优化后”。Rust 不是魔法，它生成的也是普通机器码；但因为它在编译期就把抽象”展开 / 内联 / 单态化”掉了，最终跑的那段机器码，和你不嫌麻烦、手写 C 风格循环几乎一样。换句话说，代价被转移到了编译期，运行期一毛不拔。

这就像你去餐厅点菜。普通语言像是”套餐必配例汤”，你不吃也得为那碗汤买单（运行时总有一层间接）。Rust 像是”你点什么才上什么，且后厨在你点的菜上桌前，已经把预制工序合并成了一条流水线”——你享受了”点菜”的便利（抽象），但端上来的那盘菜，和一开工就冲着这盘菜现做，没区别。

二、单态化：泛型零开销的核心引擎

泛型为什么能零成本？靠的是单态化（monomorphization）——这个词听着吓人，道理朴素：编译器在编译期，为每一种被实际用到的具体类型，单独生成一份”特化”的代码。

看个例子：

fn largest<T: PartialOrd>(list: &[T]) -> &T {
    let mut max = &list[0];
    for item in list {
        if item > max {
            max = item;
        }
    }
    max
}
 
fn main() {
    let a = largest(&[1, 5, 3]);        // T = i32
    let b = largest(&["x", "y", "z"]);  // T = &str
    println!("{a} {b:?}");
}

你只写了一遍 largest，但编译器在背后实实在在地生成了两份函数：一份是针对 i32 的 largest_i32，一份是针对 &str 的 largest_str。每份都是完全具体的、不带任何泛型参数的机器码，就像你亲手为 i32 和 &str 各写了一遍循环。

这就是单态化的全部秘密：泛型在编译期被”实例化”成具体类型的函数，于是运行时根本不存在”泛型分发”这回事——没有查表、没有指针跳转，就是一份直来直去的具体代码。

好处一目了然：性能上，特化后的代码能被进一步优化（比如循环展开、常量传播）。代价呢？代码体积会膨胀——用了 N 种类型，就生成 N 份函数。这叫”代码膨胀（code bloat）“。但注意，这个代价是编译期 / 磁盘 / 内存上的，不是运行时性能上的；对绝大多数程序，多占几 KB 二进制，换运行时零开销，血赚。

对比一下没有单态化会怎样：如果泛型靠”类型擦除 + 运行时查接口”实现（像 Java 的泛型那样走类型擦除、或像动态分发那样走虚表），那每次比较 item > max 都得通过一层间接调用，性能就掉下来了。Rust 选了”编译期展开”这条更费编译时间、但零运行时税的路。

三、内联：让抽象的边界在机器码里消失

单态化把泛型摊平，但函数调用本身还有一层成本——调用、返回、参数压栈。对于那种”薄薄一层、只为表达清晰”的小函数（比如迭代器的 next、各种 map 里的闭包），如果每次都真走函数调用，那抽象就还是有税的。

这时候**内联（inlining）**登场。编译器的优化器（LLVM）会发现：这个函数在调用点展开后，比真的跳过去调用更划算，于是它把函数体直接”粘贴”到调用处，消去调用开销。

#[inline]
fn square(x: i32) -> i32 {
    x * x
}
 
fn sum_squares(xs: &[i32]) -> i32 {
    let mut s = 0;
    for &x in xs {
        s += square(x);  // 编译器很可能把 square 内联展开成 s += x * x
    }
    s
}

#[inline] 是个提示（hint），不是命令——最终是否内联由优化器决定，它比你更懂什么时候划算。但语义上你要明白：内联后，square 这个”抽象层”在机器码里就彻底不存在了，只剩下 x * x。你写代码时享受了”语义清晰的函数封装”，运行时却像直接写了乘法。抽象被吃掉了，这就是零成本的另一半。

这里有个值得品的辩证：内联太多会让二进制变大（又是代码膨胀），所以内联是”用空间换时间”。零成本抽象从不为”没用到的”付钱，但会为”用到的、且值得的”大方地花编译期/空间成本，换运行时免费——这就是它精明的地方。

四、与 C++ 模板的类比，和关键差异

写过 C++ 的人，看到单态化会立刻想起模板（template）。没错，Rust 的泛型单态化，在机理上和 C++ 模板实例化是表兄弟：都是编译期为具体类型生成具体代码。如果你写过 C++，这里的”心智要重装”不在于机理，而在于错误报告哲学和代码膨胀的控制。

相同点：两者都在编译期展开，都生成特化代码，都能做到”抽象零运行时开销”。

差异点，墨叔点三处：

第一，错误信息友好度。C++ 模板报错是出了名的”元信息地狱”——模板一层套一层，报错能打出几十屏、指出一堆和你写的代码八竿子打不着的内部展开点。Rust 的泛型报错虽然也不短，但定位在你的调用处，且 trait bound 信息清晰得多。这是 Rust 站在 C++ 肩膀上做的体验改进。

第二，单态化的触发边界。C++ 模板是”图灵完备的”，能在编译期干非常疯狂的事（模板元编程），代价是编译极慢、心智极重。Rust 的泛型有意限制了编译期计算能力（const generics 和 const fn 是后来才谨慎放开），把”变态的编译期魔法”挡在门外，换来更可控的编译时间和更可预期的展开。

第三，代码膨胀的应对。两者都会膨胀，但 Rust 因为模块化清晰 + LTO（链接时优化）成熟，常能在链接期把重复的泛型实例合并、剔除死代码。C++ historically 在模板膨胀上更失控。

所以你可以这么记：Rust 泛型 ≈ 更克制、更安全的 C++ 模板，拿到了”零成本”的红利，规避了相当一部分”模板地狱”的痛。

五、迭代器：零成本抽象最耀眼的招牌

前面几章你写过的 iter().map().filter().collect()，本身就是零成本抽象的最佳广告。墨叔必须单独拎出来说，因为太多人以为”链式调用”必然慢。

真相：Rust 的迭代器在编译期被融合（fusion）和内联成一个紧致的循环，完全没有为每一步分配中间集合。你写：

let v: Vec<i32> = (1..=100)
    .filter(|&x| x % 2 == 0)
    .map(|x| x * x)
    .collect();

编译器会把 filter 和 map 这两个”适配器”内联进同一个循环里，等价于你手写：

let mut v = Vec::new();
for x in 1..=100 {
    if x % 2 == 0 {
        v.push(x * x);
    }
}

注意这两段在 release 下的机器码几乎一模一样。你享受了”声明式、可读、可组合”的高级写法，运行时却和手写 for 循环同样高效。这就是零成本抽象活生生的例子——它不是口号，是你每天写的 iter() 里已经发生的现实。

反而要提醒：如果你在迭代链里 .collect::<Vec<_>>() 收集一次、再 .iter() 又收集一次，那是你自己制造了不必要的分配，不是抽象的锅。零成本保证的是”抽象本身不收税”，但你乱用抽象（比如无谓地反复堆分配）照样付费——锅要分清楚。

六、benchmark 的正确心态：别靠猜，靠测

讲了这么多零成本，墨叔得泼一盆关键的水：零成本是”设计目标”，不是”你代码的性能保证书”。 你的程序慢，可能慢在算法选型、慢在错误的内存布局、慢在无谓的 clone、慢在锁竞争——这些和抽象零不零成本无关。于是引出这一节的核心：性能靠测，不靠猜。

新手最常犯的错，是”我觉得这里用迭代器比 for 循环慢""我觉得加个 clone 会爆”，然后凭直觉优化或拒绝优化。这是瞎子摸象。正确的心态是：

  • 先写清晰的代码，别 premature optimization（过早优化）。Rust 的抽象大多零成本，你先用最可读的写法写出来。
  • 用工具量化。Rust 生态里 criterion 是事实标准的基准测试（benchmark）框架，它比手写的 std::time::Instant 计时严谨得多：会自动跑多轮、做统计、消除抖动、报告置信区间。
use criterion::{black_box, criterion_group, criterion_main, Criterion};
 
fn bench_sum(c: &mut Criterion) {
    let data: Vec<i32> = (0..10_000).collect();
    c.bench_function("iter_sum", |b| {
        b.iter(|| {
            // black_box 阻止编译器把整个计算优化掉
            data.iter().map(|&x| x * x).sum::<i32>()
        })
    });
    c.bench_function("loop_sum", |b| {
        b.iter(|| {
            let mut s = 0;
            for &x in &data {
                s += x * x;
            }
            s
        })
    });
}
 
criterion_group!(benches, bench_sum);
criterion_main!(benches);

black_box 是关键技巧：它告诉优化器”别假设这个值是确定的、也别把计算整个消掉”，否则编译器聪明到直接把你的 benchmark 优化成常数，测了个寂寞。用 criterion 跑出来，你会亲眼看到 iter_sum 和 loop_sum 的耗时在同一量级——这就是零成本抽象的实证，比任何嘴上的保证都有力。

再说一遍心态：benchmark 不是用来”证明 Rust 快”的，是用来定位你代码真实的瓶颈的。墨叔见过太多人花三天优化一个本来只占 1% 时间的函数，而真正吃性能的 IO 就在旁边躺着没人管。测，才知道该优化哪；猜，只会优化错地方。

七、一个把全章串起来的小结式提醒

零成本抽象是 Rust 的脊梁之一，但它依赖三个前提才成立：单态化把泛型摊平成具体代码、内联把薄抽象边界吃掉、迭代器被融合成紧致循环。这三者都发生在编译期，所以代价是编译时间和二进制体积，运行时一毛不拔。而你作为使用者，要守住两件事：一是不滥用（别无谓分配、别错用动态分发），二是用 benchmark 说话、别靠直觉猜性能。

【思考题】

  1. 墨叔说”零成本不是抽象免费，是抽象在机器码里被消去”。请推演：如果你写了一个泛型函数 fn f<T>(x: T) -> T { x }，并且在程序里分别用 i32、String、f64 三种类型调用了它。编译后你的二进制里，这个函数会以几种形态存在？每种形态里有没有”泛型分发/虚表查找”的运行时开销？这和”零成本”的两条定义怎么对应？

  2. 内联能把小函数”粘贴”到调用处从而消去调用开销，但墨叔也说了内联是”用空间换时间”。请推一下：如果我对一个非常大、被调用了上万次的函数强行 #[inline]，会发生什么？这和单态化造成的”代码膨胀”有什么异同？什么时候内联反而可能让程序变慢（注意是变慢，不只是变大）？

  3. 你写了一段 xs.iter().filter(...).map(...).collect::<Vec<_>>()。墨叔说”零成本保证抽象本身不收税，但乱用照样付费”。请指出：这里有没有可能”乱用”导致你真的多付了运行时代价？如果有，是哪一种代价（分配？拷贝？）？又，如果你把末尾的 collect::<Vec<_>>() 去掉、直接 .count() 或 .sum()，这种”乱用”会消失吗？为什么？

【参考答案】

  1. 编译后，二进制里会有三份 f 的具体实例：f_i32、f_String、f_f64，每份都是不含任何泛型参数的具体机器码。因为单态化在编译期就为每种用到的类型生成了特化版本，所以运行时不存在任何泛型分发或虚表查找——调用 f(1i32) 就是直接跳到 f_i32，和手写三个独立函数无异。这正好对应零成本的两条：第一，“不为没用到的付钱”——如果你从没用 u64 调过 f，二进制里就不会有 f_u64，尽管你写了泛型；第二，“用到的抽象等价于手写”——那三份特化函数，性能上和你不写泛型、手写为 i32/String/f64 各写一遍完全一样。代价是二进制里多了两份函数体（代码膨胀），但这只在磁盘/内存上，不在运行时性能上。

  2. 对”非常大、被调用上万次”的函数强行 #[inline]，编译器会把它的整个函数体粘贴到每一处调用点。结果：第一，二进制体积暴涨——一份大函数体被复制了上万次；第二，更隐蔽的是，它可能导致指令缓存（icache）命中率下降——代码段太大、太分散，CPU 取指时 cache miss 增多，反而让执行变慢，这已经不只是”变大”而是”真变慢”。第三，过度内联还会阻碍编译器做跨函数优化时的整体判断，有时反而限制其他优化。它和单态化的”代码膨胀”同因（都是编译期展开导致体积涨），但来源不同：单态化是”为不同泛型类型各生成一份”，内联是”为同一函数的多处调用各复制一份体”。取舍原则：小函数、热路径上的薄封装才值得内联；大函数通常由优化器自己判断不内联更划算，人强行干预反而弄巧成拙。

  3. 这段链式调用里真正的”乱用”风险在于 collect::<Vec<_>>()：它会在堆上分配一块内存来装过滤+映射后的所有结果。如果你的目的只是”数个数”或”求和”，那你根本不需要把这些中间结果存成一个 Vec——分配这块内存、填充它、最后再丢弃，就是白白多付的运行时代价（一次堆分配 + 一次全量写入）。而如果你改成 xs.iter().filter(...).map(...).count() 或 .sum()，迭代器链会被融合进一个循环，根本不分配任何中间集合，直接边走边算，那层”乱用”就消失了。这恰恰印证墨叔的话：零成本保证的是 iter/map/filter 这些抽象本身不收税，但.collect() 是一个”明确的动作”（要物化成一个集合），你用它做不必要的事，税是你自己加的，不是抽象收的。所以优化方向是”延迟或避免物化”——只在真正需要持有集合时才 collect。

小结

零成本抽象的真意是”抽象在编译期被单态化、内联、融合而消去，运行期不收税”——泛型靠单态化摊平成具体代码，薄函数靠内联消失，迭代器链被融合成紧致循环，与 C++ 模板同源但更克制；但代价由编译期和二进制体积承担，且性能终须用 criterion 实测而非靠猜。

反向链接