第12章 优化原则与性能剖析

为什么先别急着优化

想象一条工厂流水线，整条线慢了。你不知道是哪个工位卡住，于是随手给每个工位都加人手、换快机器——结果花了大钱，整条线还是慢，甚至更慢，因为你改的不是真正的瓶颈。

这一章解决的就是这个问题：动手改之前，先用数据找出流水线上真正最慢的那个工位，确认它确实卡住了整条线，再只优化它，最后用一道检查守住"改完确实变快、也没改坏别的地方"。

没有这套方法，优化就变成猜：有人凭感觉改、有人只测一小段就宣布胜利，最后整条线的速度由一个没人测过的工位决定，而且改完没人说得清到底变快了没有。

优化三原则：先正确，再优化

官方章节围绕优化三原则、优化策略、CPU 剖析、内存剖析、网络剖析展开。原书出版于 Python 2.5 与早期工具生态，本章保留它解释"为什么"的结构；命令和安全默认按当前 Python、标准库与 PyPA 维护文档迁移，不把 EasyInstall、distutils 等历史工具直接当成新项目默认。

先让程序正确，从用户可感知目标出发，并保持代码可读可维护；没有性能基线的优化只是猜测。先确认瓶颈是否在本服务，再考虑硬件、算法或缓存，最后写速度回归测试；局部变快若让端到端更慢就不算优化。

抽象不能消除成本，只会改变成本出现的位置。包装、生成器、构建系统、CI 或缓存都必须说明资源、顺序和异常传播。

先预测：三原则、策略、CPU、内存、网络五个环节里，哪一个最容易在没有基线时就被人动手？点开每个环节，对照它的失败模式验证你的猜测。

用微基准把计时逻辑固化下来，下面两种视角对比同一段计时：

import timeit
elapsed = timeit.timeit(
    "sorted(values)",
    setup="values=list(range(1000, 0, -1))",
    number=1000,
)
print(elapsed)

setup    准备阶段 —— 构造输入，不计入耗时
number  重复次数 —— 次数太少噪声大，太多浪费时间
sorted  被测目标 —— 只隔离一个小函数，不含 I/O
elapsed 总耗时 —— 须除以 number 得单次，再与基线比较

用剖析定位真正的热点

微基准只测一小段，瓶颈往往在 I/O 或网络而非 CPU，所以要先做宏观剖析定位高耗时路径，再用微基准隔离验证。采样与插桩有不同扰动，报告要包含输入、调用次数和累计时间。

下面两种视角对比同一段 cProfile 逻辑：

python -m cProfile -o profile.out app.py
python -m pstats profile.out
# sort cumulative, then inspect the hottest call chain

cProfile   采样插桩 —— 记录每次调用耗时与调用次数
-o profile 二进制输出 —— 供 pstats 离线排序分析
sort cumulative  按累计时间排序 —— 定位最热调用链
hottest chain  热点路径 —— 优先优化占比最高的函数

内存要看当前，更要看峰值

理解对象分配、引用生命周期和峰值驻留后再定位泄漏；单看最终内存会漏掉处理中间峰值，优化也要防止复用可变对象造成错误。边界实验至少包含正常、空输入、上限附近、依赖失败和重复执行。

下面两种视角对比同一段 tracemalloc 逻辑：

import tracemalloc
tracemalloc.start()
run_workload()
current, peak = tracemalloc.get_traced_memory()
print({"current": current, "peak": peak})

start()       开始追踪 —— 之后的分配才被记录
run_workload  被测负载 —— 处理过程中分配/释放均计入
current       当前驻留 —— 此刻仍在内存中的字节
peak          峰值驻留 —— 处理中间最大占用，单看最终会漏掉

网络不能只看平均

网络性能分解为 DNS、连接、握手、服务处理和传输，并同时观察请求数与字节量；平均时延会掩盖尾部延迟与重试放大。涉及网络、并发或外部制品时，还要加入超时、取消、部分完成与摘要校验。

负责收束验收：保存解释器、依赖锁定、输入、命令、退出状态、关键输出和制品摘要，才能让另一台干净机器重放同一结论。

实战验收清单

1. 在隔离环境运行三段示例，记录解释器实现、版本和依赖来源。
2. 为核心行为增加正常、空输入、失败和重复执行测试，先看到失败再修改实现。
3. 清理缓存和临时文件后重跑，证明结果不依赖工作区残留。
4. 对历史命令写出当前替代路径，并说明保留的架构不变量与不再采用的安全默认。

迁移决策题

历史工具不等于无价值。正确迁移是先提取声明式配置、隔离、持续反馈和可回滚发布等不变量，再用维护中的接口重写；错误做法是机械替换命令却保留隐式环境和不可追踪副作用。

设想团队正在维护一个已经运行多年的 Python 服务：它仍依赖本章对应的历史工具，但业务不能停机。先不要直接重写。第一步列出优化三原则承担的真实输入和输出，再用优化策略识别构建或运行时依赖；第二步把 CPU 剖析放进隔离实验，证明当前行为与失败类型；第三步用内存剖析设计兼容层，让旧入口和新入口在同一组契约测试下运行；最后以网络剖析保存制品摘要、性能或行为差异与回滚条件。只有新路径在正常、边界和故障输入上都达到既定条件，才逐步切换流量或调用者。这样迁移的是可验证契约，而不是把一个旧命令盲目替换为一个新命令。

常见误区

误区 1

现象 → 微基准显示快了 10 倍，线上却无改善 原因 → 微基准只测了小函数，瓶颈在 I/O 或网络而非 CPU 修法 → 先做宏观剖析定位端到端热点，再用微基准隔离验证

误区 2

现象 → 优化后内存"看起来正常"，高峰期仍 OOM 原因 → 只看了最终内存，漏掉处理中间的峰值驻留 修法 → 用 tracemalloc 同时记录 current 和 peak，优化峰值

误区 3

现象 → 缓存优化后端到端反而更慢 原因 → 局部变快不等于全局变快，缓存引入了锁竞争或失效开销 修法 → 写速度回归测试，对比优化前后端到端延迟而非局部耗时

误区 4

现象 → 平均延迟下降，但用户仍抱怨慢 原因 → 平均值掩盖尾部延迟与重试放大，P99 才是体验瓶颈 修法 → 同时观察 P50/P95/P99 与重试率，不只用平均值

小结

• 先让程序正确，有性能预算和基线再优化
• 先确认瓶颈在本服务，再考虑算法或缓存
• 微基准隔离小函数，宏观剖析定位端到端热点
• 内存看当前与峰值，单看最终会漏掉处理中间峰值
• 网络分解 DNS/连接/握手/传输，平均值掩盖尾部与重试

练习与验收

名词解释