我的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)
Wed Oct 20 17:46:02 2010 mainProgram.profile
547303 function calls (542629 primitive calls) in 548.060 CPU seconds
Ordered by: internal time
List reduced from 727 to 20 due to restriction
ncalls tottime percall cumtime percall filename:lineno(function)
4 345.701 86.425 345.704 86.426 {gc.collect}
1 167.115 167.115 200.946 200.946 PlotD3PD_v3.2.py:2041(PlotSamplesBranches)
28 …