17370845950

Python性能优化需基于解释器行为与运行时约束：优先用cProfile和tracemalloc定位真实瓶颈，避免盲目缓存或Cython；预分配列表仅在长度确定时更优；asyncio不加速CPU密集任务，应配合多进程；90%性能问题源于I/O、连接或日志配置。

Python性能优化不是堆砌技巧，而是理解解释器行为、内存模型和运行时约束后的针对性干预。盲目用 @lru_cache 或改写为 cython 常常无效，甚至更慢。

为什么 timeit 测出来的快，线上反而没变化？

本地单次小数据测试掩盖了真实瓶颈：I/O等待、GIL争用、内存分配压力、缓存未命中。生产环境的 timeit 结果往往不可迁移。

• 用 python -m cProfile -s cumulative your_script.py 替代 timeit，关注 cumulative 列而非 tottime
• 对 Web 服务，优先在真实请求路径中注入 tracemalloc，捕获峰值内存分配位置：

  import tracemalloc
  tracemalloc.start()
  # ... run request handler ...
  current, peak = tracemalloc.get_traced_memory()
  print(f"Peak memory usage: {peak / 1024 / 1024:.1f} MB")

• 避免在循环内反复调用 len()、hasattr() 等——它们本身有开销，且可能触发属性查找或方法调用

list.append() 比预分配 list 更快？真还是假？

取决于增长模式。Python 的 list 底层是动态数组，扩容策略是“乘数增长”（约 1.125 倍），摊还复杂度仍是 O(1)，但频繁扩容会引发多次内存拷贝和碎片。

• 已知长度时，用 [None] * n 预分配比循环 append 快 2–3 倍（尤其 n > 10^4）
• 但若长度不确定，或中间有大量 pop()/insert()，预分配反而浪费内存且易出错
• 替代方案：对追加密集场景，考虑 collections.deque（O(1) 头尾操作，无扩容抖动）

为什么用了 asyncio，CPU 密集任务反而更慢？

asyncio 不绕过 GIL，只优化 I/O 等待。CPU 密集型协程仍被串行调度，还额外承担事件循环开销。

• CPU 密集任务必须交给 multiprocessing 或 concurrent.futures.ProcessPoolExecutor
• asyncio.to_thread()（Python 3.9+）可安全将阻塞调用扔进线程池，但仅适用于真正阻塞、非 CPU 密集的函数（如 requests.get、json.loads）
• 混合场景（如爬虫）：用 asyncio 并发发请求 + ProcessPoolExecutor 解析 HTML，两者边界要清晰，避免跨进程传大对象

最常被忽略的一点：90% 的“慢”来自重复加载、冗余序列化、未关闭的数据库连接或日志级别设为 DEBUG。先看 strace -e trace=connect,open,read,write 和 lsof -p $(pidof python)，再谈算法优化。