[Python-Dev] Optimization of the Year
Raymond Hettinger
python at rcn.com
Tue Feb 10 11:47:00 EST 2004
> If indeed such 3rd party code exists, and we expect we can't get it
> all fixed before 2.4 is released, the tracked_item hack can be used as
> a temporary measure to hunt down all those 3rd party extensions that
> break the abstraction. I propose to issue a warning when it is
> discovered that ob_item != tracked_item. Then in 2.5 we can remove
> the tracked_item feature.
That is a reasonable transition strategy, take the immediate gain
and then phase out list->tracked_item. The fix for offending code is
a simple rule: if you mess with list->ob_item, then invalidate the
list->allocated field by setting it to -1.
After adding the warning and commenting the invalidation rule, is it
okay to check this one in?
> (I think Tim's earlier attempt had about the same
> performance.)
Right. Though this one doesn't crash the testsuite and it doesn't
recompute roundupsize() on every call ;-)
> We can't be wishy-washy about this. Either we allow external code to
> tinker, or we don't. If, in fact, there is 3rd party code that
> tinkers in illegal ways, we should try to get it fixed, not work
> around it forever.
Now with a fast PyList_Append(), there is much less of a reason
to want to hack through the abstraction. Still, I'm okay with
allowing tinkering using the above invalidation rule.
Raymond Hettinger
More information about the Python-Dev
mailing list