Antoine Pitrou added the comment:
> No problem. I've been thinking about getting involved with python
> development for a while - this seemed a good place to start!
It is. You can also subscribe to the core-mentorship mailing-list if you want:
http://mail.python.org/mailman/listinfo/core-mento
Roundup Robot added the comment:
New changeset 47e6217d0e84 by Antoine Pitrou in branch '3.2':
Issue #14775: Fix a potential quadratic dict build-up due to the garbage
collector repeatedly trying to untrack dicts.
http://hg.python.org/cpython/rev/47e6217d0e84
New changeset 7951900afd00 by Anto
Tim Silk added the comment:
> Thank you for doing this!
No problem. I've been thinking about getting involved with python development
for a while - this seemed a good place to start!
> Do you have a real name so that I can credit you?
Yes (thankfully) - I've added it to my profile.
> Also,
Antoine Pitrou added the comment:
> I have written up some documentation on how untracking is handled in
> the gc - please see the attached patch.
Thank you for doing this! Do you have a real name so that I can credit you?
Also, could you fill a contributor agreement? http://www.python.org/psf/
stw added the comment:
> So the tuple is linked-in to the garbage collection list before its
> contents are constructed?
> It is. It typically happens when you do (in C code):
Ok, thanks. I couldn't see how a tuple could be created before its contents in
python code, but it is clearly possibl
Antoine Pitrou added the comment:
Le mercredi 23 mai 2012 à 16:22 +, stw a écrit :
> So the tuple is linked-in to the garbage collection list before its
> contents are constructed?
It is. It typically happens when you do (in C code):
PyObject *my_tuple = PyTuple_New(2);
/* compute some_obj
stw added the comment:
> I had a thought about untracking tuples. If a tuple contains only
> immutable objects (atomics and tuples of atomics etc), then it should
> be untracked. Once untracked, it will never need to be tracked again
> since the tuple is immutable. If a tuple contains mutable ob
Antoine Pitrou added the comment:
> I had a thought about untracking tuples. If a tuple contains only
> immutable objects (atomics and tuples of atomics etc), then it should
> be untracked. Once untracked, it will never need to be tracked again
> since the tuple is immutable. If a tuple contains
stw added the comment:
I had a thought about untracking tuples. If a tuple contains only immutable
objects (atomics and tuples of atomics etc), then it should be untracked. Once
untracked, it will never need to be tracked again since the tuple is immutable.
If a tuple contains mutable objects
Antoine Pitrou added the comment:
> Also, am I right in thinking that whether a container gets untracked or
> not depends not only on its contents, but also on the order of the
> objects in the gc list? That is, all of the contents of a container
> must get untracked before the container is con
stw added the comment:
> Probably because memoization itself uses a dict.
Right, but as far as I can tell it's not the memo dict that keeps being
tracked/untracked. Rather, it's the dict that is being unpickled.
Anyway, I suppose the point is that the issue of whether an object is
tracked/un
Antoine Pitrou added the comment:
> However, this only seems to be true if the pickle file is created
> using pickle - it doesn't happen with files generated with cPickle.
> With cPickle the dict remains tracked, and passes from generation 0 to
> 1 to 2. The only difference is that pickle memoiz
stw added the comment:
I'd come to the same conclusion - as the new dict is built up (using batch
build) it keeps appearing in generation 0, and the gc has to walk over it to
determine that it should be untracked.
However, this only seems to be true if the pickle file is created using pickle
Antoine Pitrou added the comment:
Okay, found it. The problem is _PyDict_MaybeUntrack() is potentially O(n), so
calling it in every GC collection can produce quadratic runtimes when a dict is
building up. Attached patch (for 3.3) only calls it in the older collections.
Not sure this should be
14 matches
Mail list logo
