Python垃圾回收(gc)拖累了程序执行性能

浅谈Python垃圾回收机制

在使用C语言开发时代,我们的开发效率(生产力的问题)受牵制于内存释放、泄露等问题,于是普遍的口号---“指针好难学”。时过境迁,当今的流行的语言都配套了内存自动回收机制,从而使我们有更多的精力去纠结于业务上处理。
常用的垃圾回收(GC)算法有这几种引用计数(Reference Count)、Mark-Sweep、Copying、分代收集。在Python中使用的是前者引用计数,工作原理:为每个内存对象维护一个引用计数。因此得知每次内存对象的创建与销毁都必须修改引用计数,从而在大量的对象创建时,需要大量的执行修改引用计数操作(footprint),对于程序执行过程中,额外的性能开销是令人可怕的,由于该算法的特性问题,因此无法避免了,那么我们只能成垃圾回收时机着手了。
谈到这里因此不得不谈谈垃圾回收的时机,根据官方的描叙,Python中,有2中方式将会触发垃圾回收:
1、用户显示调用gc.collect()
2、每次Python为新对象分配内存时,检查threshold阀值,当对象数量超过threshold设置的阀值就开始进行垃圾回收。

调优之前

为了便于描叙如前文所述的加载大量原始数据的问题,使用了虚假的数据,这部分程序片段完成的功能倒没有发生变化,以下是调优之前的程序片段:

Python代码 复制代码 收藏代码
  1. data = range(1,5000000)   
  2. wdict = dict(zip(data,data))  
data = range(1,5000000)
wdict = dict(zip(data,data))

使用time python test.py运行,我们可以看到以下结果(机器的差异,显示的结果也将不同):

Python代码 复制代码 收藏代码
  1. real    0m39.066s  
  2. user    0m26.422s  
  3. sys     0m12.313s  
real    0m39.066s
user    0m26.422s
sys     0m12.313s

如果使用linux下的top命令,您将动态的看到内存的使用情况,该程序运行后将缓慢的吞噬内存,由于程序运行时的内存对象都是有效的,因此垃圾回收触发时,无法释放这部分内存,而垃圾回收程序却在做无用功(达到threshold阀值),显而易见,程序的执行性能将大打折扣。那么我们的调优手段也就很容易了,在程序片段运行的这段时间内禁止进行垃圾回收。

调优之后

以下是调优之后的程序片段(禁止程序片段的垃圾回收):

Python代码 复制代码 收藏代码
  1. import gc   
  2. gc.disable()   
  3. data = range(1,5000000)   
  4. wdict = dict(zip(data,data))   
  5. gc.enable()  
import gc
gc.disable()
data = range(1,5000000)
wdict = dict(zip(data,data))
gc.enable()

使用time python test.py运行,我们可以看到以下结果(机器的差异,显示的结果也将不同):

Python代码 复制代码 收藏代码
  1. real    0m2.760s  
  2. user    0m1.208s  
  3. sys     0m1.532s  
real    0m2.760s
user    0m1.208s
sys     0m1.532s

通过上面的运行结果对比,显而易见,调优后的程序性能明显大幅提升,如果使用Linux下的top命令,您将动态的看到内存的使用情况也是不同的,该程序运行后迅速的吞噬内存,对比调优之前的程序片段,减少了垃圾回收的频频触发。

总结

通过这次的调优体验,发现Python垃圾回收频频触发将会影响程序执行的性能,因此,正如很多同学所说,Python程序的执行速度慢是不是有垃圾回收机制的一份功劳

展开阅读全文

没有更多推荐了,返回首页