优化闭环：从假设、改动到回归守护 / Optimization, Regression and Production

性能分析的终点不是找到一个热点。

真正的终点是：提出一个能被证伪的假设，做一个尽量小的改动，证明端到端目标改善，同时不破坏正确性、资源边界和可维护性。

然后把这个收益守住。

1. 好优化从好假设开始

一个好假设包含四件事：

• 现象；
• 机制；
• 改动；
• 预期指标。

例如：

现象：
  32 线程后吞吐不再提升，P99 变差。

证据：
  时间线显示提交阶段锁等待占 38%；
  持锁线程在临界区内做序列化和日志。

机制：
  全局提交锁把并行阶段重新串行化。

改动：
  按 shard 拆分提交队列，日志移出临界区。

预期：
  锁等待下降，吞吐提升，P99 不再随线程数恶化。

这比“试试无锁队列”好得多。

因为它清楚说明了为什么改、改什么、看什么。

2. 一次只改变一个主要因素

性能优化很容易越改越多。

你同时改算法、编译选项、数据布局、线程数和日志，就算快了，也不知道是谁带来的收益。

更好的节奏是：

假设 A
  |
  v
最小改动
  |
  v
复测
  |
  +-- 成立：记录并推进
  |
  +-- 不成立：回到证据

不是每次实验都要保留代码。

很多实验只是为了排除方向。例如固定单线程验证锁竞争、预加载文件验证 I/O、禁用日志验证系统调用、改变输入规模验证算法复杂度。

失败实验也有价值。它让你少在错误方向上花时间。

3. 优化优先级

常见优先级是：

1. 删除无用工作；
2. 降低算法复杂度；
3. 减少数据移动；
4. 改善数据布局和局部性；
5. 批处理固定开销；
6. 降低锁、屏障和串行区；
7. 改善并行调度；
8. 使用 SIMD、GPU 或专用库；
9. 最后再做难维护的微架构特化。

这个顺序不是法律。

Profile 证据优先。

如果热点明确受内存带宽限制，优先减少字节流量。若热点来自算法复杂度，换容器和调指令都只是绕远。

4. 正确性和性能一起验

性能优化最怕把错结果跑得很快。

每次改动后同时看：

• 单元测试；
• 集成测试；
• 领域校验；
• 输出校验和；
• 浮点误差；
• 日志和诊断；
• 异常路径；
• 取消和超时；
• 峰值内存；
• 线程安全；
• 资源释放。

数值计算尤其要小心。

并行化、SIMD、GPU、快速数学库、混合精度和重新排序都可能改变浮点结果。不能只比较是否运行成功，要比较误差边界、残差、收敛行为和工程可接受标准。

5. 优化可能引入的新成本

一个改动可能让目标指标变好，却把成本转移到别处。

例如：

• 批处理提高吞吐，但增加单请求延迟；
• 缓存减少计算，但增加峰值内存和失效复杂度；
• 多线程提高平均速度，但恶化尾延迟；
• 对象池减少分配，但复杂化生命周期；
• SIMD 提高局部性能，但增加平台特化；
• GPU 加速 Kernel，但增加传输和同步；
• 异步化减少等待，但让错误处理更难；
• 降低日志量减少 I/O，但削弱问题诊断。

所以性能报告必须同时写收益和代价。

收益：
  median 导入时间 -24%，P95 -31%。

代价：
  峰值内存 +420 MB；
  首次初始化 +180 ms；
  新增一个批量读取缓存，需要失效策略。

6. 性能 CI

性能收益如果没有守护，几周后就可能消失。

CI 可以分层：

Pull Request
  +-- 快速微基准
  +-- 小型组件基准

Nightly
  +-- 大输入组件基准
  +-- 多线程伸缩基准

Release
  +-- 端到端场景
  +-- 硬件矩阵
  +-- 长时间稳定性

Production
  +-- 灰度指标
  +-- Trace / Profile
  +-- 成本与容量

PR 阶段不能跑太重，否则开发者会绕开它。

重基准放到 Nightly 或 Release 更合理。

阈值要大于自然噪声。噪声 5% 的基准，不适合设置 1% 的硬门禁。

7. 基线管理

性能基线不是永远不变。

硬件、系统、编译器、依赖、输入和产品目标都会变化。

重建基线时要记录原因：

2026-08-24
  重建原因：CI 机器从 12 核升级为 16 核，旧基线不再可比。
  保留旧数据：yes
  新基线提交：abc123

不要为了让报警消失而静默更新基线。

基线变化本身就是工程事件。

8. 生产验证

本地基准只覆盖你选择的输入。

生产包含更多租户、文件、硬件、网络、后台任务、依赖状态和极端路径。

灰度时观察：

• P50、P95、P99；
• 成功吞吐；
• 超时和重试；
• CPU、内存、磁盘、网络、GPU；
• 队列长度；
• 下游压力；
• 错误码；
• 成本；
• 不同输入规模和租户分组；
• 回滚后的恢复时间。

线上指标要能和版本关联。

否则性能退化发生时，你只能看到曲线变坏，却不知道是哪次发布引入。

9. 线上 Profile 和隐私边界

线上采样 Profile 很有价值，但要控制边界。

要考虑：

• 采样率；
• 开销；
• 权限；
• 符号化；
• 数据保留周期；
• 用户隐私；
• 文件路径和参数是否敏感；
• 是否可能采到业务数据；
• 是否会影响低延迟路径；
• 是否支持按版本聚合。

生产 Trace 不应默认记录完整输入、明文请求体、密钥、个人信息或客户文件路径。

性能可观测性也要遵守安全边界。

10. 回滚策略

优化可能改变数据格式、缓存键、任务调度和并发语义。

不是所有性能改动都能简单切回旧二进制。

发布前要问：

• 是否改变持久化数据；
• 是否改变缓存内容；
• 是否需要双写或版本字段；
• 是否能关闭新路径；
• 是否有 feature flag；
• 回滚后旧版本能否读新数据；
• 长任务中途切换会怎样；
• 是否会留下后台任务或临时文件。

对高风险优化，先加开关，再灰度，再扩大。

11. 性能复盘

一次完整优化结束后，最好留下复盘。

复盘不需要很长，但要留下以后能复用的经验：

问题：
  大工程打开慢。

根因：
  属性表逐条同步读取，主线程等待 Worker。

有效手段：
  批量读取 + 主线程不等待中间阶段。

无效尝试：
  优化字符串解析，局部快 12%，端到端无明显变化。

守护：
  新增 large-project-open benchmark，P95 阈值 13 s。

风险：
  峰值内存增加，后续要观察 16 GB 机器。

无效尝试尤其值得记录。

它能防止团队过几个月再次重复同样的弯路。

12. 本篇总结

优化闭环的关键是证据链。

现象
  -> 工作负载
  -> 基线
  -> 证据
  -> 假设
  -> 最小改动
  -> 复测
  -> 回归守护
  -> 生产验证

性能工程不是一次性英雄行为，而是一套能持续保护项目的工程制度。

当团队能稳定写出这样的证据链，WPR、WPA、VTune、perf、Nsight 这些工具才真正变成生产力。