New submission from darrenr <python-roun...@dranalli.com>: Python's garbage collector holds GIL during collection and doesn't provide any method of interruption or concurrency with other Python threads within a single Python VM. This can be a problem for realtime applications. The worst-case performance of the garbage collector takes linear time with respect to the number of Python objects that could potentially be involved in a garbage cycle. I've attached timings taken on a Core 2 Quad 2.4 GHz (WinXP Pro, 3GB RAM), with ever-increasing numbers of objects. The gc at worst takes upwards of 3 seconds before the process runs out of memory.
If gc periodically released the GIL it would allow it to be put in a separate thread, but as it stands it blocks the Python VM for periods of time that are too long for realtime interactive applications. Alternatively a gc that is incremental by default would eliminate the need for a second thread. ---------- files: gctimings.zip messages: 78646 nosy: darrenr severity: normal status: open title: garbage collector blocks and takes worst-case linear time wrt number of objects versions: Python 2.4, Python 2.6, Python 3.0 Added file: http://bugs.python.org/file12510/gctimings.zip _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue4794> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
