Home Original page

[Python-Dev] int/float freelists vs pymalloc

Vladimir Marangozov Vladimir.Marangozov at t-online.de
Tue Feb 19 12:37:45 CET 2008 
May I chime in? :-)

Gents, the current implementation of Python's memory management
is really fine and most problems it used to have in the past
have been fixed in recent years (at least the ones I know of).

Probably the only one left, indeed, is the potential unbounded
growth of int/float objects' freelists (beyond the shared cache
of small ints).  Yet, this seems to be a questionable problem
because any change in the freelists' management will invariably
slow down their allocation.  By how much, I don't know, but
whether you fallback to pymalloc above a certain threshold or
use something else, the change will have a generic perf hit.

The explanation is simple: you can't beat the free list scheme
performance when you have frequent short bursts of allocations
and deallocations, which is the typical Python pattern observed
on New() & DECREF() calls.

BTW if you have 2 AMD combos showing speedups noone can explain
in an obvious way, then it's a cache effect.

Optimizing pymalloc for non-standard byte-sizes is a no go, and
although I've seen suggestions for further optimizations tailored
to ints and floats, I haven't seen anyone spelling out what that
optimization of pymalloc would consist of.

MAL's suggestion to preallocate a pymalloc pool cache for certain
object sizes is something I actually implemented in the earliest
versions of pymalloc, but eventually dropped in favor of the
current dynamic, on-request allocation because pre-allocating pools
(and initializing the free lists) costs time and in general leads
to degraded performance in the average case.  I can't perf this
now to prove it, but that was very clear at the time when I wrote
the original stuff and applied the regression test on it.

So I would kindly suggest to get down to the only problem (if any)
which is the uncontrolled growth of the specialized freelists, the
shared int cache notwithstanding.  If you can limit a degenerative
growth without a noticeable generic perf sacrifice, that would
sound like an improvement to me, but so far I haven't seen any
convincing arguments.

And, of course, if the int/float freelist scheme was a real issue
we would have probably heard of it by now in a very sound way.

Vladimir
More information about the Python-Dev mailing list