Antoine Pitrou <pit...@free.fr> added the comment: Le jeudi 18 décembre 2008 à 06:12 +0000, Martin v. Löwis a écrit : > I think this approach is difficult to maintain, and also may miss some > objects.
But what counts is where tuples can be created in massive numbers or sizes: the eval loop, the tuple type's tp_new, and a couple of other places. We don't need to optimize every single tuple created by the interpreter or extension modules (and even the, one can simply call _PyTuple_Optimize()). > I'd rather see that integrated into collection: e.g. when iterating over > survivors of a collection, check whether they can be untracked. That's what I had tried at first, but it crashes. I haven't investigated, but I suspect removing an object from the GC list while that list is being walked isn't very well supported by the GC. Also, this approach is more expensive since it involves checking tuples again and again each time they are walked by the GC. The patch only does it once, when the tuple is being built. _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue4688> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
