如何在Rust基准测试中正确使用条件编译的对比函数

现有方案合理性与更优替代 #

你当前通过构建脚本检测工具链版本条件编译的方案是完全合理的，生产环境可以正常使用，但存在更轻量的实现方案，不需要引入构建脚本和额外依赖：
你尝试Criterion框架失败的核心原因是基准测试默认不会触发test编译配置，只要调整slow函数的编译条件即可解决，完全可以在稳定版Rust上实现需求：

1. 在Cargo.toml中新增一个默认关闭的特性：

[features]
bench-slow = []

2. 修改slow函数的编译条件：

#[cfg(any(test, debug_assertions, feature = "bench-slow"))]
pub fn slow(x: T) -> U { ... }

3. 跑Criterion基准测试时启用该特性即可：

cargo bench --features bench-slow

这个方案没有额外的构建依赖，逻辑更直观，也不需要依赖Nightly工具链，是更推荐的实现方式。
如果确实需要使用Nightly的内置bench框架，也可以不用构建脚本，直接将特性声明的条件改成：

#![cfg_attr(all(test, feature = "nightly-bench"), feature(test))]
#[cfg(all(test, feature = "nightly-bench"))]
mod bench;

跑基准时用cargo +nightly bench --features nightly-bench即可，同样可以避免稳定版编译报错。

慢实现基准测试的其他应用场景 #

• 性能劣化回归检测：每次迭代修改fast实现后，同时对比两个实现的性能数据，可快速发现意外的性能下降，避免优化效果随版本迭代流失
• 边缘场景性能校验：对于极端输入（如哈希碰撞、完全逆序的排序输入等），fast实现可能出现性能退化，和slow实现的基准对比可以快速定位这类异常
• 跨环境性能校准：不同硬件、编译器版本、编译优化参数下的绝对性能数据没有可比性，以slow实现的性能作为统一基线，可以跨环境校准优化效果，避免环境差异导致的误判
• 性能调优参考：对比两个实现的CPU profiling结果，可以快速定位fast实现中仍存在优化空间的热点逻辑，提升调优效率
• 正确性补充验证：基准测试通常会使用大量随机输入，跑基准时同时验证两个实现的输出一致性，相当于附带了模糊测试的效果，覆盖单元测试没考虑到的输入场景

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