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

起因

前段时间，在做文本处理的实验时，需要预加载大量的原始数据（100W），在Python中使用的字典（dict）类型负责保存这些数据，很快就开发完成了一个Demo版，然而程序执行的效率不是那么令人满意，通过使用Python中的profile发现，影响程序执行性能的关键语句就那么几条（用 dict保存加载后原始数据，这是个循环遍历。）

解决问题

既然找到了问题源，于是就勒起衣袖开始动手尝试使用各种解决方案替代效率不佳的，经过多次的反复尝试，调优的效果不太明显，最后一个idea：考虑Python垃圾回收机制的影响了，最后也证明了这个想法的靠谱程度，本文后续部分将分享调优的过程与测试结果。

浅谈Python垃圾回收机制

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

调优之前

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

Python代码

data = range(1,5000000)
wdict = dict(zip(data,data))

使用time python test.py运行，我们可以看到以下结果（机器的差异，显示的结果也将不同）：

Python代码

real 0m39.066s
user 0m26.422s
sys 0m12.313s

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

调优之后

以下是调优之后的程序片段（禁止程序片段的垃圾回收）：

Python代码

import gc
gc.disable()
data = range(1,5000000)
wdict = dict(zip(data,data))
gc.enable()

使用time python test.py运行，我们可以看到以下结果（机器的差异，显示的结果也将不同）：

Python代码

real 0m2.760s
user 0m1.208s
sys 0m1.532s

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

总结

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

例外豆瓣算法工程师阿稳的一个类似的情况：

这两天在调试一个耗时大户的数据载入模块，因为时间的耗费居然主要都花在数据载入、解析、格式化上了，虽然处理的是很大量的数据，但还是心有不甘，不解决它使得后面的算法调试工作很难快捷深入的进行下去。

通过profile检查之后，把调试的目标锁定为文本解析的那一行代码上。因为数据的导出虽有几秒的耗时，但导出后数据的解析才是大头，只是这么一句简单的语句：

[row.split(',') for row in records]

很显然地，我会毫不犹豫地把罪魁祸首指定在split的身上。于是试图采用其它的方法来取代它，无论map还是直接取切片的方式都试过，就差没有用C来重写split函数了。但收效甚微。我甚至考虑把数据源切换到mysql，以避免做数据split这一步，但mysql的大数据量导出速度让我无法忍受。

无意中我用time.time()来计算了一下时间，很令人郁闷又很令人惊喜地发现，包含该行解析语句的子程序会越跑越慢。每次处理100W行的记录，第一次7秒，第二次14秒。如果从整个程序来启动这个模块，更加无法让人接受：7、15、50+、100+、200+。如果你的子程序运行得一次比一次慢，你会感觉生活很没有盼头。但我似乎找到真正的原因了：慢不是因为它本来就慢，而是在做同样的事情，却变得越来越慢。

于是想起以前Davies给我推荐过的一篇文章，讲python的垃圾回收（Garbage Collection）机制对程序性能的影响。当时由于主要并不是那个原因，所以没有太多研究。但这次的现象我可以原原本本地对上号，很有可能是因为数据量太大，处理过程中留下太多暂时不能清除的变量，而python的垃圾回收却在一遍一遍地扫这些不断在增长的列表，导致程序受到的影响越来越大。赶紧证实一下，import gc，然后在数据载入模块前gc.disable（）,结束后再gc.enable()。结果原来要跑将近两个小时的程序，这下不用5分钟就跑完了。cool~！用gc.get_count()也证明了之前的猜想，在第一次运行之后临时变量数目就从几百上升到百万，并一直在涨。

由此我想，是不是有很多python新手对python速度的责难，都是因为这个原因呢（其实我觉得python基本模块的速度还是很快的:-)）。另外，如果你的python程序在处理大数据量的问题，并且出现某个子程序在做同样量的工作，却越跑越慢的情况，恭喜你，你也许可以在这里对号入座，找到答案了。