每周性能技巧 #90：如何进行估算
本节阅读量:本文翻译自 Abseil 官网的 Performance Tip of the Week #90: How to estimate。
原文发布于 2025 年 2 月 4 日，作者 Chris Kennelly，更新于 2025 年 10 月 1 日。
许多软件工程问题都涉及估算：项目需要多久完成？不同备选方案的成本有多高？移除一个间接层能改善多少性能？本篇讨论如何构造有用估算，并展示当额外精度不再改变决策时，什么时候可以停止。
为什么估算
估算的价值不在于得到一个完美数字，而在于帮助我们做决策。如果两个方案的收益差距是 10 倍，一个粗略估算可能就足够。如果二者非常接近，则需要更仔细地测量或承认结果太接近，无法单靠该指标决策。
一个估算应该回答“这个数量级是否合理”。它可以帮助我们在投入大量工程时间之前，识别不可能带来足够收益的方向。估算也可以帮助我们解释为什么一个微基准结果不太可能转化为生产收益，或者为什么一个看似很小的局部改善在规模化后很重要。
从已知量开始
好的估算通常从容易获得的事实开始：
- 代码路径在生产中出现的频率。
- 每次调用大致消耗多少 CPU、内存或 I/O。
- 优化能影响其中多大比例。
- 成本是否会被缓存、批处理或并行执行摊销。
把这些数字相乘，可以得到一个初始上界。这个上界尤其有用：如果最乐观情况下收益仍然太小，就可以停止。如果上界很大，才值得继续寻找更精确的数据。
用边界约束结果
估算时，先问“最大可能有多大”和“最小可能有多大”。这些边界可以防止我们被单个观测值带偏。
例如，一个函数占某服务 CPU 的 5%。即使把它优化到零，服务整体最多也只能快 5%。如果优化只影响该函数中 20% 的工作，那么整体收益上界就是 1%。这种简单乘法能迅速告诉我们，项目是否值得继续。
同样，如果某个缓存命中优化只影响很少请求，或者只减少已经被其他工作隐藏的延迟，那么它可能不会影响用户可见结果。估算要关注最终瓶颈，而不只是被修改代码片段本身。
使用单位
写下单位可以防止很多错误。CPU 秒、请求数、字节、每秒查询数和机器数量之间的换算，都应该明确写出来。
单位也能帮助我们发现不合理的结果。如果估算得出某个优化能节省的 CPU 超过整个服务实际使用量，说明某个假设或换算错了。如果一个内存优化声称节省巨大 RAM，但对象生命周期很短，可能忽略了峰值与累计分配量之间的区别。
让估算可检验
估算不是一次性产物。随着项目推进，我们应该用更精确的信息更新它：
- 微基准可以验证单次操作是否真的更快。
- 负载测试可以显示局部收益是否在更真实环境中保留。
- 生产 profile 可以确认该路径是否足够热。
- A/B 实验可以捕捉共享资源和负载均衡带来的外部性。
每一步都应该更新我们对项目收益的先验。如果新数据与估算严重冲突，这不是失败，而是帮助我们找到遗漏假设的信号。
何时停止
估算不需要无限精确。它只需要精确到足以支持下一步决策。
如果估算已经显示机会非常大，下一步可能是构建原型，而不是再花几天寻找更漂亮的数字。如果估算显示机会很小，下一步可能是放弃或寻找更大的瓶颈。如果估算区间跨越决策边界，才值得收集更多信息。
结语
估算是性能工作的导航工具。它把模糊直觉转化为可讨论、可检验的假设，让我们能更快聚焦真正有影响的项目。
