[Python-Dev] Object free lists

Tim Peters tim.one at comcast.net
Tue Jun 15 22:52:10 EDT 2004


[Eric Huss]
> Is there a plan to switch the basic objects (int, float, method, etc.) to
> use pymalloc instead of the block allocation technique they currently
> use?

No.  pymalloc is slower than a simple dedicated free list.

> The reason I ask is because the free_list in these objects is unbounded.

Also immortal (once memory has been allocated for an int (float, etc), it
can never go away, or be used for anything else, for the life of the
process).

> It becomes a problem in a server environment if activity spikes cause
> different types of objects to start eating memory and never give it up.

Yup.

> The only problem I see with using pymalloc is that the objects won't be
> stored in memory in such a compact way.

The difference can be large, because pymalloc aligns to 8-byte boundaries.
So, e.g., on most boxes today a Python int object consumes 12 bytes, but
would consume 16 if allocated with pymalloc.  That's a 33% boost, and that
can be significant for apps hanging on to lots of ints.

OTOH, on most boxes there would be no real size difference for float
objects.

> I would imagine there would be no performance difference.

Sorry, there is -- and it's in the wrong direction <wink>.

> Of course some optimizations (such as small_ints) would stay.
>
> I would be willing to submit a patch with the change if there is
> interest.

I think you'd have better luck with a patch that bounded the sizes of these
free lists.  That's not hard to do; e.g., look at the simple bounded free
list in frameobject.c.  I wouldn't like a small limit on ints or floats, but
letting any subsystem suck up unbounded resource forever does cause
problems.





More information about the Python-Dev mailing list