[!info] related notes

• 所属 MOC：运行时 · 学习路线
• 相关：多进程 · C 扩展

Python 性能方法论

这个概念为什么出现

“Python 慢”常是未测的借口。真实瓶颈可能是 N+1 查询、错误结构或网络。方法论保证优化花在刀刃上。

[!abstract] 一句话理解 定义指标 → 复现 → 画像/测量 → 改算法或 IO → 回归验证；不凭感觉微优化。

最小可观察示例

场景：对比两种聚合实现的耗时

# perf_count_methods.py
# 业务意图：比较计数循环与 Counter。
# 教学点：粗计时示例；正式比较用重复基准，热点定位用 profiler。

from collections import Counter
from time import perf_counter


def count_loop(xs: list[str]) -> dict[str, int]:
    d: dict[str, int] = {}
    for x in xs:
        d[x] = d.get(x, 0) + 1
    return d


def main() -> None:
    xs = ["a", "b", "a", "c"] * 50000
    assert count_loop(xs) == Counter(xs)  # 先核对同一输入的计数结果
    t0 = perf_counter(); count_loop(xs); t1 = perf_counter()
    t2 = perf_counter(); Counter(xs); t3 = perf_counter()
    print("loop≈", round(t1 - t0, 4), "counter≈", round(t3 - t2, 4))


if __name__ == "__main__":
    main()

建议运行：

python perf_count_methods.py

期望输出：两段耗时数字（机器相关）。

结合场景再看三个关注点

1. 单次粗测有噪声，且固定先后顺序会影响缓存/预热；比较要记录版本、输入并重复测量，不保证 Counter 总是更快。
2. 正确性先于速度。
3. cProfile/py-spy 用于定位热点，有各自开销与盲区；性能比较用 timeit/pyperf 等重复基准，并验证端到端指标。

核心概念与准确模型

1. 复杂度与数据结构
2. IO/数据库/序列化
3. 解释器开销 vs 原生库
4. 并发是否对症

边界情况与反直觉行为

1. 微基准误导（缓存、CPU 频率）
2. 优化破坏可读性 无测试兜底
3. 过早并行 更慢

常见误区

[!warning] 常见误区：先重写 Rust 再说 错误理解：语言是第一瓶颈。
正确模型：先算法与 IO；真热点再下沉。

工程实践

• 预算延迟/吞吐
• 画像进 CI 可选
• 保留可读基线

本节总结

性能是工程过程，不是口号。测量驱动变更。

自测题

1. 优化三步？
2. 为何单次计时不够？

参考答案

1. 测量定位、修改、验证回归。
2. 噪声大，需重复与统计直觉。

延伸阅读与资料来源

资料	类型	支撑内容
cProfile	文档	画像
time.perf_counter	文档	计时