比较循环与迭代器的性能：Rust 零成本抽象的威力

一、引言

在早期的 I/O 项目中，我们通过对 String 切片的索引和 clone 操作来构造配置结构体，这种方法虽然能确保数据所有权的正确传递，但既显得冗长，又引入了不必要的内存分配。随着对 Rust 迭代器特性的深入了解，我们可以通过直接传递 env::args 返回的迭代器、利用 next 方法和迭代器适配器（如 filter、map、collect）重构代码，使代码表达更明确、逻辑更清晰，同时保持高性能。

二、循环 vs. 迭代器：性能对比

2.1 Benchmark 结果

为了比较两种实现方式的性能，我们对 search 函数进行了基准测试。测试中，我们将《福尔摩斯探案全集》的全部内容加载到一个 String 中，并搜索其中的单词 “the”。以下是使用显式 for 循环和迭代器实现的 search 函数的基准测试结果：

test bench_search_for  ... bench:  19,620,300 ns/iter (+/- 915,700)
test bench_search_iter ... bench:  19,234,900 ns/iter (+/- 657,200)

可以看出，两种实现方式的性能几乎相当。这表明尽管迭代器是一种高层次抽象，但编译器会将其优化成与手写循环相似的高效代码，从而实现所谓的零成本抽象。

三、零成本抽象：迭代器的优化原理

Rust 设计迭代器时的目标就是实现零成本抽象。也就是说，使用迭代器这种高层抽象并不会带来额外的运行时开销，编译器会将这些抽象优化为与手动编写的低级循环代码无异的高效机器码。

3.1 迭代器适配器与闭包

例如，在 search 函数中，我们可以将原本依赖可变向量的循环重构为：

rust">pub fn search<'a>(query: &str, contents: &'a str) -> Vec<&'a str> {contents.lines()                           // 创建一个行迭代器.filter(|line| line.contains(query)) // 使用闭包过滤包含查询词的行.collect()                         // 将结果收集到 Vec 中
}

这种写法使用了 filter 和 collect 适配器，闭包在内部完成判断逻辑。编译器能够将这些高层次操作内联和优化，消除闭包调用的开销。

3.2 循环展开与寄存器分配

更进一步看一个真实世界的例子，在音频解码器中，我们需要利用线性预测算法来计算未来的采样值。下面的代码使用了迭代器链：

rust">let buffer: &mut [i32];
let coefficients: [i64; 12];
let qlp_shift: i16;for i in 12..buffer.len() {let prediction = coefficients.iter().zip(&buffer[i - 12..i]).map(|(&c, &s)| c * s as i64).sum::<i64>() >> qlp_shift;let delta = buffer[i];buffer[i] = prediction as i32 + delta;
}