Re:Why Python Is Slow: Looking Under the Hood
by dalke on Tuesday November 18, 2014 @03:12PM
(#8626034)
Of course it's solvable. My point is that solving it adds a layer of complexity. Now every decref needs a check for "id". As the id is implemented as a pointer, all of these special objects need to be allocated in a contiguous block of memory for this check to be fast, and with two extra if-conditionals. Also, this range can't change without recompiling all extensions ... or that range must be resolved dynamically, adding more overhead for every single decref.
Nor is there much advantage. We know that more advanced implementations can look at program flow and determine that, say, certain operations are only integer based, and therefore unboxable. Or tracing systems can assume that certain types are constant over multiple calls to the same code, and write optimized versions for those types.
These gives much better (eg, >5x according PyPy) optimizations over the error prone change that you believe might be faster.
"Objects with IDs between 0 and 2055, inclusive, are considered unreleasable. The Python runtime shall initialize the refcount of these objects to 1 when they are first used, and shall make no guarantee that the refcount on such objects accurately reflects the true number of references to that object. Native extensions may increase and decrease the refcount on these objects as if they were normal objects; if those extensions are well-behaved, then the refcount should never decrease below 1. However, native extensions that can statically reason about whether an object is likely to be unreleasable, may benefit in performance by checking for whether objects passed to their functions are indeed unreleasable, and refraining from modifying or checking their refcount in such cases."