每周性能技巧 #7：面向应用生产效率进行优化
本节阅读量:本文翻译自 Abseil 官网的 Performance Tip of the Week #7: Optimizing for application productivity。
原文发布于 2019 年 6 月 6 日，作者 Chris Kennelly，更新于 2025 年 10 月 3 日。
概览
Google 管理着庞大服务器 fleet，用来处理搜索查询、处理记录和转码视频。我们购买这些服务器，并不是为了在 TCMalloc 中分配内存、把 protocol buffers 塞进其他 protocol buffers，或者处理处理器的分支预测失败。
为了提高 fleet 效率，我们希望优化服务器的生产力，也就是每 CPU 秒、每 RAM 字节秒、每次磁盘操作，或每次硬件加速器使用，能完成多少有用工作。衡量一个 job 的资源消耗很容易，但如果没有帮助，要判断它完成了多少有用工作就更难。
任务 CPU 使用上升，可能表示任务发生性能回退，也可能只是更忙。看一个服务随时间变化的 CPU 使用图，并按二进制版本分解总 CPU 使用，仅凭观察无法判断 CPU 增长来自工作负载增加，还是效率降低。
要判断真实发生了什么，我们需要一个捕捉真实工作完成量的生产力指标。如果知道处理了多少单位工作，就可以计算每 CPU 秒完成的真实工作更多还是更少。这类指标称为应用生产效率指标，简称 APM。
如果没有生产效率指标，一整类优化就无法被现有指标很好表示：
- 通过核心基础设施变化带来的应用加速。TCMalloc 的 hugepage 感知分配器 Temeraire 展示了显著加速，但改善来自应用性能，而不是 TCMalloc 自身耗时减少。我们可能在 TCMalloc 中花更多相对时间，却大幅改善应用性能。只盯着 TCMalloc 相对时间会得到方向相反的结论，让我们降低优先级甚至回滚强正向优化。
- 在 Arena 上分配更多 protocol buffer 消息，不只加速 protobuf 代码本身，也加速使用它们的业务逻辑。在主要框架中启用 Arena 让它们每 CPU 可以处理 15% 到 30% 更多工作，而 protobuf 析构成本只占很小一部分。数据局部性改善可以给整个应用带来超出局部成本的收益。
- 新指令集。随着硬件代际演进，厂商在 ISA 中加入新指令。未来硬件上，我们期望用微码优化的
rep movsb代替memcpy调用，它可能比手写汇编序列更快。rep movsb的 IPC 可能较低，因为它用一条指令取代了整个复制循环。只看 MIPS 或 IPC 会让我们偏好执行更多指令的实现，即使它复制n字节所需时间更长。启用 AVX、FMA 和 BMI 指令集可能显示 MIPS 回退，同时改善应用生产效率。 - 编译器优化。内联等技术减少函数序言，并启用进一步简化优化。动态执行指令更少，通常意味着更快、更有生产力的代码。
- 内核优化。内核在 hugepage、线程调度和其他系统参数上有很多策略。即使策略改变让内核名义上更昂贵，例如做更多工作来压缩内存，应用收益也可能轻松超过成本。
这些指标的可用性，可以帮助基础设施和效率团队更有效地指导工作。
本节目录