基准测试优化循环 是做什么的？
使用此技能将“使其快20倍”或“尝试50次递归优化”转化为一个有界的、可测量的循环过程，从而实际改进系统。
所需基线
在以下条件满足之前，不要进行优化：
- 正在被优化的操作；
- 必须保持绿色的正确性门控；
- 指标：墙钟时间、p95延迟、行/秒、运行成本、内存、错误率；
- 当前基线；
- 搜索预算：最大变体数、最大时间、最大花费、最大数据影响。
如果用户要求不切实际的目标，则保留其雄心，但使循环有界且可测量。
循环
- 测量基线。
- 从证据中识别瓶颈。
- 生成每次测试一个假设的变体。
- 使用相同的输入形状运行变体。
- 拒绝那些正确性、安全性或可重复性失败的变体。
- 推广最快的安全变体。
- 将获胜路径固化到脚本、命令、测试、配置或文档中。
- 重新运行基线和获胜者以确认差值。
变体表
像这样跟踪变体：
变体 | 假设 | 命令 | 时间 | 正确？ | 备注
baseline | 当前路径 | npm run job | 120s | 是 | 稳定
batch-500 | 减少往返次数 | npm run job -- --batch 500 | 42s | 是 | 胜利者
parallel-8 | 更多工作进程 | npm run job -- --workers 8 | 31s | 否 | 速率受限
递归搜索
对于递归或超参数工作：
- 持久化每次运行到日志；
- 与之前接受的获胜者比较，而不仅仅是前一次运行；
- 保持留出或回放检查；
- 当改进在噪声范围内、正确性失败、成本超出预算或搜索开始改变比它能够解释的更多的变量时停止。
使用“最佳可测量的安全变体”之类的短语，而非“全局最优”，除非搜索空间实际上是穷举的。
推广门控
一个变体在以下条件满足之前不能成为新的默认值：
- 正确性测试通过；
- 性能差异是可重复的或被解释；
- 回滚路径清晰；
- 更改已写入源代码控制或持久的运行手册；
- 最终摘要包含精确的命令和测量结果。