python - Python垃圾回收会那么慢吗？

Question

我的python应用程序有问题，我认为这与python垃圾回收有关，即使我不确定...

问题是我的应用程序需要花费很多时间才能退出并切换到下一个功能。

在我的应用程序中，我处理非常大的字典，其中包含成千上万个大对象，这些大对象是从包装的C ++类实例化的。

我在程序中添加了一些时间戳输出，并且看到在每个函数的末尾，当在函数内部创建的对象超出范围时，解释器会在调用下一个函数之前花费大量时间。当程序退出时，我在应用程序结尾处观察到了同样的问题：在屏幕上的最后一个时间戳与出现新提示之间花费了很多时间（〜小时！）。

内存使用情况稳定，因此我确实没有内存泄漏。

有什么建议？

可能是成千上万个缓慢的大型C ++对象的垃圾回收吗？

有什么方法可以加快速度吗？

更新：

非常感谢您的所有回答，您给了我很多调试我的代码的提示:-)

我在Scientific Linux 5上使用Python 2.6.5，这是基于Red Hat Enterprise 5的自定义发行版。
实际上，我不是在使用SWIG来获取C ++代码的Python绑定，而是在Reflex / PyROOT框架上。我知道，这在外部粒子物理学领域不是很为人所知（但仍是开源的并且可以免费获得），我必须使用它，因为它是我们主要框架的默认设置。

在这种情况下，Python方面的DEL命令不起作用，我已经尝试过了。 DEL仅删除链接到C ++对象的python变量，而不删除对象本身在内存中的内存，内存仍然由C ++拥有...

...我知道，我猜这不是标准的，有点复杂，抱歉：-P

但是，按照您的提示，我将分析我的代码，然后按照您的建议再次提供详细信息。

其他更新：

好的，按照您的建议，我用cProfile插入了代码，发现实际上gc.collect()函数是占用最多运行时间的函数！

这是cProfile + pstats print_stats（）的输出：


>>> p.sort_stats（“ time”）。print_stats（20）
2010年10月20日星期三17:46:02 mainProgram.profile

548.060 CPU秒中的547303函数调用（542629原语调用）

排序：内部时间
由于限制，列表从727个减少至20个

ncalls tottime percall cumtime percall filename：lineno（function）
4 345.701 86.425 345.704 86.426 {gc.collect}
1167.115 167.115 200.946 200.946 PlotD3PD_v3.2.py:2041(PlotSamplesBranches）
28 12.817 0.458 13.345 0.477 PlotROOTUtils.py:205(SaveItems）
9900 10.425 0.001 10.426 0.001 PlotD3PD_v3.2.py:1973(HistoStyle）
6622 5.188 0.001 5.278 0.001 PLOTROOTUtils.py:403(__init__）
57 0.625 0.011 0.625 0.011 {内置方法负载}
103 0.625 0.006 0.792 0.008 dbutils.py:41(DeadlockWrap）
14 0.475 0.034 0.475 0.034 {'cPickle.Pickler'对象的方法'转储'}
6622 0.453 0.000 5.908 0.001 PlotROOTUtils.py:421(CreateCanvas）
26455 0.434 0.000 0.508 0.000 /opt/root/lib/ROOT.py:215(__getattr__）
[...]

>>> p.sort_stats（“ cumulative”）。print_stats（20）
2010年10月20日星期三17:46:02 mainProgram.profile

548.060 CPU秒中的547303函数调用（542629原语调用）

排序依据：累积时间
由于限制，列表从727个减少至20个

ncalls tottime percall cumtime percall filename：lineno（function）
1 0.001 0.001 548.068 548.068 PlotD3PD_v3.2.py:2492（主要）
4 0.000 0.000 346.756 86.689 /usr/lib//lib/python2.5/site-packages/guppy/heapy/Use.py:171（堆）
4 0.005 0.001 346.752 86.688 /usr/lib//lib/python2.5/site-packages/guppy/heapy/View.py:344（堆）
1 0.002 0.002 346.147 346.147 PlotD3PD_v3.2.py:2537(LogAndFinalize）
4 345.701 86.425 345.704 86.426 {gc.collect}
1167.115 167.115 200.946 200.946 PlotD3PD_v3.2.py:2041(PlotBranches）
28 12.817 0.458 13.345 0.477 PlotROOTUtils.py:205(SaveItems）
9900 10.425 0.001 10.426 0.001 PlotD3PD_v3.2.py:1973(HistoStyle）
13202 0.336 0.000 6.818 0.001 PlotROOTUtils.py:431（绘图画布）
6622 0.453 0.000 5.908 0.001 / root / svn_co / rbianchi / SoftwareDevelopment

[...]

>>>


因此，在两个输出中，分别按“时间”和“累积”时间排序的gc.collect()是消耗程序最多运行时间的函数！ :-P

这是内存分析器Heapy的输出，就在返回main()程序之前。

返回之前的内存使用情况：
一组65901对象的分区。总大小= 4765572字节。
索引计数％大小％累计％种类（类别/类别的字典）
0 25437 39 1452444 30 1452444 30条
1 6622 10 900592 19 2353036 49格PlotROOTUtils.Canvas
2 109 0 567016 12 2920052 61模块的字典
3 7312 11 280644 6 3200696 67元组
4 6622 10 238392 5 3439088 72 0xa4ab74c
5 6622 10 185416 4 3624504 76 PlotROOTUtils。画布
6 2024 3 137632 3 3762136 79个类型
7263 0 129080 3 3891216 82 dict（无所有者）
8254 0 119024 2 4010240 84类型的字典
9 254 0 109728 2 4119968 86型
索引计数％大小％累计％种类（类别/类别的字典）
10 1917 3 107352 2 4264012 88功能
11 3647 5 102116 2 4366128 90 ROOT.MethodProxy
12 148 0 80800 2 4446928 92级
13 1109 2 39924 1 4486852 93 __builtin __。wrapper_descriptor
14239 0 23136 0 4509988 93列表
15 87 0 22968 0 4532956 94字典guppy等胶水接口
16644 1 20608 0 4553564 94个类型.BuiltinFunctionType
17 495 1 19800 0 4573364 94 __builtin __。weakref
18 23 0 11960 0 4585324 95字典guppy.etc.Glue.Share
19 367 1 11744 0 4597068 95 __builtin __。method_descriptor



知道为什么，还是如何优化垃圾回收？

我可以做更详细的检查吗？

Answer 1

This is known garbage collector issue in Python 2.6在分配许多对象而未取消分配其中任何一个对象时，导致垃圾回收的二次时间。人口众多。
有两种简单的解决方案：


在填充大列表之前先禁用垃圾收集，然后再启用它

l = []
gc.disable()
for x in xrange(10**6):
  l.append(x)
gc.enable()

或更新为 Python 2.7, where the issue has been solved


我更喜欢第二种解决方案，但并非总是这样；）