You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Don't needlessly change refcounts of dummy objects for sets #62997
AFAICT, there is no reason for sets to incref and decref dummy objects. The dummy object address is used as placeholders in the hash table but it is never accessed by set the logic. As long the one reference is held at the time the dummy object is created, nothing further is served by the increfs and decrefs.
I can take them out entirely or use ifdefs to keep them for debug builds.
I can't think of any counter-indication but I think we shouldn't distinguish between debug and non-debug mode. That way the debug hooks can check that the refcounting optimization is right.
Activity
rhettinger commentedon Aug 21, 2013
AFAICT, there is no reason for sets to incref and decref dummy objects. The dummy object address is used as placeholders in the hash table but it is never accessed by set the logic. As long the one reference is held at the time the dummy object is created, nothing further is served by the increfs and decrefs.
I can take them out entirely or use ifdefs to keep them for debug builds.
Does anyone know of any issues?
pitrou commentedon Aug 21, 2013
I can't think of any counter-indication but I think we shouldn't distinguish between debug and non-debug mode. That way the debug hooks can check that the refcounting optimization is right.
rhettinger commentedon Aug 21, 2013
That makes good sense.
Attaching a new patch without the #ifdefs.
python-dev commentedon Aug 22, 2013
New changeset ac6dab1819c4 by Raymond Hettinger in branch 'default':
bpo-18797: Remove unneeded refcount adjustments for dummy objects.
http://hg.python.org/cpython/rev/ac6dab1819c4