Rust中变量存储中间值与内联表达式的运行时开销对比

核心结论：优化编译下无性能差异 #

在Rust的release模式（cargo build --release）下，你示例中的temporary_assignments和inlined函数性能完全一致，不会有任何运行时开销差异。

Rust的编译器基于LLVM，会自动执行常量传播、死代码消除、寄存器分配优化、冗余计算消除等一系列操作。对于示例里的纯数值计算逻辑，编译器会直接把临时变量的计算逻辑合并，最终生成的机器码和内联表达式版本完全相同。

debug模式下可能存在细微差异，但debug模式本身是为调试设计，未开启性能优化，这种差异没有实际参考价值。

临时变量的优势（而非劣势） #

用临时变量存储中间值不仅没有性能问题，反而有明显好处：

• 代码可读性更强：每个中间值都有明确命名（比如discrim代表判别式），其他人一眼就能理解逻辑。
• 调试更方便：debug模式下可以直接查看每个临时变量的值，快速定位问题。
• 维护成本更低：修改某一步计算时，直接调整对应变量即可，不用在嵌套表达式里查找修改位置。

内联表达式可能带来性能提升的极端场景 #

绝大多数情况下，内联表达式不会比临时变量更快，反而会牺牲可读性。只有在非常极端的边缘场景下，才可能出现性能差异：

• 编译器无法完成优化的特殊情况：比如中间值计算涉及编译器无法跟踪的外部状态（比如调用了带副作用且无法内联的外部函数），导致临时变量无法被消除。但这种情况非常罕见，通常可通过调整代码或优化编译选项解决。
• 底层嵌入式/汇编级优化：在完全禁用编译器优化的场景下（比如部分嵌入式系统的特殊需求），手动内联可能减少变量存储的栈操作，但这属于小众需求，普通应用开发无需考虑。

示例代码回顾 #

// 使用变量赋值为最终结果的中间部分命名，再将这些变量组合得到最终结果。
fn temporary_assignments(a: f32, b: f32, c: f32) -> f32 {
    let fourac = 4. * a * c;
    let discrim = b * b - fourac;
    let rad = discrim.sqrt();
    let denom = 2. * a;
    (-b + rad) / denom
}

// 使用字面量直接表达完整的最终结果。
fn inlined(a: f32, b: f32, c: f32) -> f32 {
    (-b + (b * b - 4. * a * c).sqrt()) / (2. * a)
}

内容的提问来源于stack exchange，提问作者RBF06