On 02/10/2007, Adam Olsen <rhamph at gmail.com> wrote: > > On 10/1/07, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote: > > Justin Tulloss wrote: > > > Would > > > somebody care to give me a brief overview on how the current gc module > > > interacts with the interpreter > > > > The cyclic GC kicks in when memory is running low. Since > > This isn't true at all. It's triggered by heuristics based on the > total number of allocated objects. It doesn't know how much memory is > available and is not called if an allocation fails. Correct. And that reminds me of the limitation of the the Python GC: it doesn't take into account how much memory is being indirectly retained by a Python Object. Like in the example I already gave, gtk.gdk.Pixbuf can easily hold hundreds of megabytes, yet the GC gives it as much consideration as it does to a simple python integer object which is several orders of magnitude smaller. If someone wanted to improve the GC, that person should consider adding a protocol for the GC to retrieve the ammount of memory indirectly held by a python object, and take such memory into consideration in its heuristics. -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-dev/attachments/20071002/38ad21d7/attachment.htm
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4