This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author rhettinger
Recipients pitrou, rhettinger, serhiy.storchaka, tim.peters
Date 2015-01-18.20:58:59
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1421614739.25.0.753169549852.issue23259@psf.upfronthosting.co.za>
In-reply-to
Content
I'll just close this one.  There seems to be little interest in it.

Originally, I characterized freeslot tracking as an optimization that mildly benefited an uncommon case (adds/deletes/moreadds) at the expense of the common cases (uniquification, membership testing, and set-to-set operations).

As Antoine pointed-out, on some systems the cost of a predictable branch routinely not take can be almost zero.  There was still benefit in code simplification, reducing the size of the stack frame, freeing a register that needed to saved and restored when called PyRich_CompareBool(), etc. But no one seems to care about those.

As Serhiy found, there is one case where the freeslot tracking benefit wasn't "mild".  In the unusual but possible case of deleting and reinserting the exact same value in a large set, dummy reuse prevents a catastrophic linear pile-up.

And so it goes.   Free slot tracking lives.
History
Date User Action Args
2015-01-18 20:58:59rhettingersetrecipients: + rhettinger, tim.peters, pitrou, serhiy.storchaka
2015-01-18 20:58:59rhettingersetmessageid: <1421614739.25.0.753169549852.issue23259@psf.upfronthosting.co.za>
2015-01-18 20:58:59rhettingerlinkissue23259 messages
2015-01-18 20:58:59rhettingercreate