每周性能技巧 #60：进程内性能分析：经验教训

本节阅读量:

---

本文翻译自 Abseil 官网的 Performance Tip of the Week #60: In-process profiling: Lessons learned。

原文发布于 2023 年 8 月 7 日，作者 Chris Kennelly，更新于 2025 年 6 月 20 日。

进程内 profiling 让程序在运行时收集自身行为数据。本篇总结构建和使用这类 profiler 的经验：如何控制开销、避免偏差，并让数据真正指导优化。

为什么在进程内

外部 profiler 很有用，但进程内 profiler 可以访问更多语义信息。它可以知道对象大小、容器状态、分配调用点、特定库内部事件，甚至把这些信息与业务上下文关联。

这种能力也带来风险：profiler 本身可能改变被测程序。设计时必须把开销和偏差放在第一位。

采样

采样是控制开销的关键。不是每个事件都需要记录；只要采样策略无偏，足够多样本就能估算总体行为。

采样点要谨慎选择。若只在某些路径上采样，结果会偏向这些路径。若采样决策太晚，可能漏掉短生命周期对象。若采样成本太高，大家会关闭 profiler。

元数据

Profiler 收集的数据必须足够解释问题，但不能过度昂贵。

有用元数据包括：

• 调用栈。
• 分配大小。
• 对象生命周期。
• 容器容量、大小和冲突信息。
• 线程、进程或服务上下文。

元数据越多，开销和隐私风险越高。设计应围绕实际要回答的问题，而不是尽可能记录一切。

可操作性

Profile 的目标是改变行动。数据应该能帮助回答：

• 哪些调用点最值得优化。
• 是否存在异常分布或长尾。
• 某个优化是否改变了预期指标。
• 哪些用户受影响最大。

如果数据很精细但无法指导下一步，价值就有限。报告格式、聚合维度和可视化都应该围绕可操作性设计。

结语

进程内 profiling 能照亮通用 profiler 看不到的行为，但它必须低开销、低偏差、并能指向行动。好的 profiler 是优化基础设施，而不只是数据收集器。

---

---