[issue4794] garbage collector blocks and takes worst-case linear time wrt number of objects

darrenr added the comment: Regardless of the type of algorithm used by the garbage collector that currently exists in Python, its worst-case performance is undesirable. I have some interest in implementing a garbage collector for Python with improved performance characteristics but don't really

[issue4794] garbage collector blocks and takes worst-case linear time wrt number of objects

Martin v. Löwis added the comment: > Python is a great > language and I think it deserves an incremental implementation of > garbage collection. Python's cyclic garbage collector is incremental. If you can provide a specific patch to replace it with something "better", please submit it as a sep

[issue4794] garbage collector blocks and takes worst-case linear time wrt number of objects

darrenr added the comment: I ask because in my opinion a three-second pause on a modern machine is significant for any program with any sort of interactivity--significant enough to warrant a warning in the documentation. Python is a great language and I think it deserves an incremental implement

[issue4794] garbage collector blocks and takes worst-case linear time wrt number of objects

Martin v. Löwis added the comment: > OK cool, that's the development strategy we've already adopted. Is this > limitation of Python's garbage collector in relation to real-time > applications documented anywhere? Why do you ask? (this is OT for the bug tracker) It's not in the Python documentat

[issue4794] garbage collector blocks and takes worst-case linear time wrt number of objects

darrenr added the comment: OK cool, that's the development strategy we've already adopted. Is this limitation of Python's garbage collector in relation to real-time applications documented anywhere? ___ Python tracker _

[issue4794] garbage collector blocks and takes worst-case linear time wrt number of objects

Martin v. Löwis added the comment: Hard real-time applications written in Python should not rely on the cyclic garbage collector. They should call gc.disable at startup, and completely rely on reference counting for releasing memory. Doing so might require rewrites to the application, explicitly

[issue4794] garbage collector blocks and takes worst-case linear time wrt number of objects

darrenr added the comment: A 'stop-the-world' garbage collector that periodically released the GIL could be run in a second thread, allowing the main thread to break in and do some processing. However the nature of a stop-the-world collector means that it probably would not easily be able to dea

[issue4794] garbage collector blocks and takes worst-case linear time wrt number of objects

Benjamin Peterson added the comment: The garbage collector will never be able to run in a second thread because it manipulates Python objects, which the GIL is supposed to protect! As for non-linear complexity, see #4688 and #4074 for some attempts to sooth this problem over. -- nosy:

[issue4794] garbage collector blocks and takes worst-case linear time wrt number of objects

Changes by David W. Lambert : -- nosy: +LambertDW ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.py

[issue4794] garbage collector blocks and takes worst-case linear time wrt number of objects

Changes by darrenr : -- components: +Interpreter Core type: -> resource usage ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue4794] garbage collector blocks and takes worst-case linear time wrt number of objects

New submission from darrenr : 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 collec