On 6/29/06, René Dudfield <[EMAIL PROTECTED]> wrote:
I just tested this with python2.5 beta 1, and it does not free all of
the memory. So I guess this bug is not yet fixed after all.
thanks for checking that out - I am curious about this whole thing
I looked at the post about the patch closer
(http://mail.python.org/pipermail/python-dev/2006-March/061991.html)
and it looks like it was put on a branch in earlry march, so I suppose
it might not be in the Beta (still on the branch)?
Or maybe it's in, but many arena's could still not be freed due to
allocated objects in them?
So what kind of memory usages before and after were you seeing? (I saw
155MB before and 124MB after in task manager on python 2.3 WinXP with
the 10mil element list)
I also tried it with some large dicts. No goodness.
I assume you mean the mem wasn't freed...? (from what I could tell
reading about the mem pools, the allocation for dictionary elements
and list elements are pooled, so I guess that's consistent with no
patch)
This is the test that Tim Peters posted as a way to see the
effectiveness of the patch to the python mailing list, so I assume if
this one still frees very little, the patch must not be in
x = []
for i in xrange(1000000):
x.append([])
raw_input("full ")
del x[:]
raw_input("empty ")
when it's "full" I see 39MB, when it's "empty" I see 34MB in the task
manager, all with python 2.3 WinXP
Also note that C programs can not free certain amounts of memory too.
I assume that what you are talking about here is that the OS allocates
memory in chunks larger then the c libraries allocation routines do,
so free'd memory won't be returned to the OS until all allocated
memory in the block is free (which is basically the same situation
that the python arena allocation that the patch will implement)
