Python cProfile 慢函数 怎样处理

Python 程序变慢时，不要先凭感觉改某一行代码。更稳妥的处理方式是先用 cProfile 跑一遍真实业务场景，把结果保存下来，再用 pstats 分别看累计时间、自身时间、调用次数和调用关系。这样可以先回答“慢在哪里”，再回答“该改什么”。

官方地址：https://docs.python.org/3.15/library/profile.html

如果只想找最值得先处理的函数，先看 cumulative；如果已经知道调用路径、想找函数内部的热点，再看 time。高调用次数还要结合单次成本判断，不能只看某一个数字。

一、先用 cProfile 覆盖完整业务场景

cProfile 适合回答函数调用层面的整体问题。命令行方式最省事，既能直接看报告，也能把报告保存为 .prof 文件，方便后续反复筛选：

# 采集完整脚本的函数调用统计，并把结果保存下来
python -m cProfile -o profile.prof app.py

# 按累计耗时直接打印前 20 个条目
python -m cProfile -s cumulative app.py

第一条命令适合排查，因为保存后的数据可以用多种排序方式重复阅读。第二条命令适合快速观察，但它只展示一次排序结果。采集时应尽量使用能稳定复现慢问题的输入，避免只分析启动阶段或一个空请求。

二、先看 cumulative，再看 time

拿到 profile.prof 后，用 pstats.Stats 分别排序。cumulative 会把一个函数及其子调用消耗的时间合在一起，更适合先判断哪条调用路径值得深入；time 更接近函数自身执行的时间，适合已经锁定路径后查内部热点。

import pstats
from pstats import SortKey

# 读取 cProfile 的结果，并去掉冗长路径，方便比较函数名
stats = pstats.Stats("profile.prof").strip_dirs()

# 先看包含子调用的累计耗时，定位主调用路径
stats.sort_stats(SortKey.CUMULATIVE).print_stats(12)

# 再看函数自己的耗时，寻找内部循环或昂贵操作
stats.sort_stats(SortKey.TIME).print_stats(12)

常见误判是把累计时间最大的函数直接当成“函数内部最慢”。例如一个入口函数可能只是调用了多个子函数，它的累计时间很高，但自身代码几乎没有成本。此时应继续看 time，或者从累计排名中的下一层函数继续下钻。

三、用调用关系确认慢函数的来源

当一个函数在累计排名靠前时，下一步不是马上重写它，而是确认它为什么被调用。print_callers() 查看谁调用了它，print_callees() 查看它又调用了谁：

from pstats import SortKey
import pstats

# 先把目标函数筛到前 20 个，再展开它的上游调用者
stats = pstats.Stats("profile.prof").strip_dirs()
stats.sort_stats(SortKey.CUMULATIVE)
stats.print_stats(20)
stats.print_callers("parse_records")

# 查看目标函数内部调用了哪些下游函数
stats.print_callees("parse_records")

这里的函数名过滤是为了缩小阅读范围，不是新的性能指标。若 parse_records 被一个循环调用数万次，即使单次执行不慢，也可能贡献很高的累计时间；若它只调用几次但自身 time 很高，则更可能是内部算法、重复转换或不必要的对象创建。

四、把优化动作收敛到一个可验证的改变

定位后一次只改一个因素：减少重复调用、把重复解析移到循环外、缩小输入、替换明显的高成本操作，或调整数据访问方式。改完后重新跑同一业务场景，确认热点是否移动；不要因为某个函数排名下降，就直接认定整体性能已经改善。

如果要比较两个很小的表达式或函数实现，使用 timeit 更合适。它的测量对象更小，能减少完整业务噪声：

import timeit

def parse_with_loop(values):
    # 只演示局部计算；真实项目中应使用与业务一致的输入
    result = []
    for value in values:
        result.append(value.strip().lower())
    return result

def parse_with_comprehension(values):
    # 用同一输入比较另一种实现，避免把数据准备时间算进去
    return [value.strip().lower() for value in values]

values = [" Python "] * 1000

# 重复多轮测量局部实现，比较最稳定的一组结果
loop_time = timeit.repeat(lambda: parse_with_loop(values), repeat=5, number=1000)
comprehension_time = timeit.repeat(
    lambda: parse_with_comprehension(values), repeat=5, number=1000
)
print(min(loop_time), min(comprehension_time))

timeit 的结果只说明这段受控代码在当前环境下的相对表现，不能替代 cProfile 对真实请求、真实数据和真实调用路径的观察。尤其是 I/O、缓存、网络等待和垃圾回收会改变全链路结论。

五、常见误区与处理顺序

1. 只看第一名。 先看累计时间，再对照自身时间和调用次数，避免把入口函数误判为内部热点。
2. 把分析器耗时当最终耗时。 cProfile 会带来采集开销，适合定位，不适合直接当作上线基准。
3. 一次改很多处。 这样即使总耗时变化，也很难知道是哪项改变有效；应保持输入和场景一致。
4. 用微基准代替业务画像。 timeit 只用于局部比较，完整路径仍要回到 cProfile 或实际指标。

可以把整个过程记成一条短流程：先采集，按 cumulative 找路径；再按 time 和 calls 找内部热点；用 callers/callees 解释来源；最后用 timeit 比较一个小改动，并重新采集确认结果。

相关问题

cProfile 的 cumulative 和 time 应该先看哪个？

先看 cumulative 找主路径，再看 time 判断函数自身是否昂贵。二者回答的问题不同，不能互相替代。

为什么调用次数很多但累计时间不高？

通常是单次成本很低；是否需要优化要看总耗时占比，以及调用是否处在高频请求路径上。

pstats 报告能不能直接比较不同机器？

不建议直接比较绝对时间。应尽量固定输入、Python 环境和运行条件，并把它用于同一环境下的前后对比。