命令行性能基准测试实战

先承认一个事实：你以为的「更快」通常没有证据

grep 和 ripgrep 哪个更快？sed 和 awk 在当前这台机器上谁更稳？一个 shell 函数优化之后，到底快了多少？这类问题最常见的回答是「我感觉应该是……」「以前测过一次」。问题在于，命令执行时间受缓存冷热、系统负载、CPU 调频、磁盘缓存、并发进程影响，单次执行的结果基本没有参考价值。没有基线，优化就无从谈起；没有对比，选型只能靠信仰。

这个技能解决的就是这个问题：把「感觉更快」变成可复现的数字。

核心能力与关键步骤

1. 先建立可信的基线

最小可用的调用长这样：

• --warmup：先跑一次预热，避免首次磁盘或网络冷启动污染均值
• --runs N：多次运行取统计值，默认 10 次，低于 5 次的结论不可信
• 输出包含 mean、min、max 和标准差——请优先看标准差，而不是只看均值

2. 多候选对比与参数化扫描

可以把多个实现放在一起对比，例如同时比较三种写法。需要看不同输入规模下的表现时，用参数化方式扫描（如不同文件大小），再把结果导出为 result.json 这类机器可读格式，方便后续做趋势分析。

3. 把基准测试写进 CI

这是最有价值的一步。在 PR 中跑固定基准，与 main 分支的 result.json 对比，性能劣化超过阈值（如 +15%）直接报错。配合 --prepare 在每次运行前准备环境（比如生成临时文件）、--cleanup 收尾，基准就从「偶尔跑一次」变成「每次提交都守门」。

4. 常见的坑

• 不做 warmup：冷启动数据混进均值，结论直接失真
• runs 太少：噪声掩盖真实差异，两个实现可能根本没区别
• 在共享机器或降频机器上跑，然后拿这个数据和别人横向对比
• 忽略标准差：均值接近但波动剧烈，说明这个结论不稳定，不该下判断
• 对比时没有控制变量：输入、工作目录、权限都不一致，比了也白比

适用边界

这个技能用的是 hyperfine 方法论，适合单条命令或脚本的相对耗时对比，不是 APM 也不是分布式链路追踪。跨机器、跨版本的基准数字只能作相对参考，落地到生产环境之前，请在目标机器上重新测一遍。AI 给出的用法请以 hyperfine 官方文档为准。