最近发现项目API请求比较慢,通过抓包发现主要是response时间太长,于是就开始进行优化工作。优化工作的关键一步是定位出问题的瓶颈,对于优化速度来说,从优化函数执行时间这个维度去切入是一个不错的选择。
本文侧重分析,不展开如何优化
利器
工欲善其事,必先利其器,我们需要一套方便高效的工具记录函数运行时间。说是一套工具,但对于一个简单项目或者日常开发来说,实现一个工具类足矣,由于实现比较简单,直接上代码:
1 | 复制代码from functools import wraps |
原始代码可以参考gist
如下,实现了3个装饰器函数func_time
,func_cprofile
,func_line_time
,分别对应
- 简单输出函数的执行时间
- 利用python自带的内置分析包
cProfile
分析,它主要统计函数调用以及每个函数所占的cpu时间 - 利用
line_profiler
开源项目,它可以统计每行代码的执行次数和执行时间。
使用说明
我们以一个简单的循环例子来说明一下,
1 | 复制代码def test(): |
func_time
关于func_time
我觉得没什么好说的,就是简单输出下函数调用时间,这个在我们粗略统计函数执行时间的时候可以使用
如下:
1 | 复制代码@func_time |
func_cprofile
cProfile
是python内置包,基于lsprof的用C语言实现的扩展应用,运行开销比较合理,没有外部依赖,适合做快速的概要测试
1 | 复制代码@func_cprofile |
输出说明:
单位为秒
- 第一行告诉我们一共有3个函数被调用。
正常开发过程,第一行更多是输出类似
194 function calls (189 primiive calls) in 0.249 seconds
,(189 primiive calls)表示189个是原生(primitive)调用,表明这些调用不涉及递归
2. ncalls表示函数的调用次数,如果这一列有两个数值,表示有递归调用,第一个是总调用次数,第二个是原生调用次数。
3. tottime是函数内部消耗的总时间(不包括调用其他函数的时间)。
4. percall是tottime除以ncalls,表示每次调用平均消耗时间。
5. cumtime是之前所有子函数消耗时间的累积和。
6. percall是cumtime除以原生调用的数量,表示该函数调用时,每个原生调用的平均消耗时间。
7. filename:lineno(function)为被分析函数所在文件名、行号、函数名。
func_line_time
line_profiler
可以生成非常直接和详细的报告,但它系统开销很大,会比实际执行时间慢一个数量级
1 | 复制代码@func_line_time() |
输出说明:
单位为微秒
- Total Time:测试代码的总运行时间
- Line:代码行号
- Hits:表示每行代码运行的次数
- Time:每行代码运行的总时间
- Per Hits:每行代码运行一次的时间
- % Time:每行代码运行时间的百分比
总结
日常开发中,可以使用func_time
,func_cprofile
做基本检查,定位大致问题,使用func_line_time
进行更细致的深入检查。
注:
func_line_time
还可以检查函数内部调用的函数执行时间,通过follow
参数指定对应的内部调用的函数声明即可,该参数是个数组,也就是说可以检查多个内部调用的函数
本文转载自: 掘金