Python memory usage

Jonathan Ballet multani at
Mon Nov 13 22:19:37 CET 2006

Le Mon, 13 Nov 2006 21:30:35 +0100,
Fredrik Lundh <fredrik at> a écrit :

> Jonathan Ballet wrote:
> >>
> > 
> > Is it still true with Python 2.5 ?
> > 
> > I mean, [] should fix this
> > behaviour, doesn't it ?
> not really -- that change just means that Python's object allocator
> will return memory chunks to the C allocator if the chunks become
> empty, but as the FAQ entry says, there are no guarantees that
> anything will be returned at all.  it all depends on your
> application's memory allocation patterns.

Ah ok, I thought memory was much "directly freed" to system (but I
misread the faq).

Is there any documents on good application's memory allocation
patterns ?

> (did you read Evan's presentation material, btw?)

I re-read it (thx for mentioning it), but schemas on pages 7, 8 and 9
are not very clear to me.

(snip some questions, since I find answers will writing them).

Where are stored pools which are not completely free ? (not in
'usedpools' nor in 'freepools' objects) (ah, this is the
partially_allocated_arenas I guess :) )
Are 'usedpools' and 'freepools' arenas ?

Smalls objects are stored in free blocks, so a block has a length of 256
bytes I guess. Can its size change (smaller, maybe larger) ?

So, if I am correct :
    - I create a new 'small' object -> Python allocates a new arena, and
stores my object in a free block in one of the pool of this arena
    - this arena is stored in the partially_allocated_arenas list
(Python 2.5)
    - allocating more objects fills all the blocks of every pools of the
arena -> all pools are going one by one into 'usedpools' object
    - del-eting every created object in my Python program free every
blocks of every pools of the arena (with a lot of chance :) ), and pools
are going into the 'freepools' object
    - if all pools from an arena are freed, the arena is freed
    - else, the arena stay allocated, in order to be re-used


More information about the Python-list mailing list