memory problems

Robin Dunn wrote:
> If I understand correctly, Python never releases memory back to the
> OS, but it will reuse what has been freed before. This is something
> that was being discussed for Python 2.5, but I don't know the outcome
> of the discussion.
>
yes, but we have the same result even if we do a gc.collect()

Under certain circumstances, Python will not release some kinds of
memory back to the operating system, regardless of whether you do
gc.collect() or not.

Want to see an example? Open up a Python console. Check Python's
memory use. Now do (without quotes) "a = range(1000000);del a". Notice
how Python now uses about 12 megs more than it did before (on a 32 bit
machine and 32 bit compiled Python)? Go ahead and do gc.collect(),
memory use won't go down. Why? It has to do with type freelists, an
optimization which does block allocations to minimize memory
fragmentation and malloc/free thrashing. If you want to learn more,
search google for "integer freelist python", which may or may not be
applicable to arbitrary wxPython types.

In 2.5 (to be released this fall), if I remember correctly, if a
particular freelist only has unused types, Python will consider freeing
that block of memory.

>> def h():
>> f = wxFrame(root, -1, '')
>> f.Show()
>> id = wxNewId()
>> b = wxButton(root, id)
>> EVT_BUTTON(b,id, h)
>
> Which platform and version are you seeing this growth on?
>
python 2.3.5 and wxPython 2.6.0.0

Yeah, wxNewId() just returns integers that were higher than before.
During binding, I would imagine that along with the event, you also
store a reference to the integer id, which is then never freed because
you never unbind the particular event (which will also suck up memory
over time).

- Josiah

ยทยทยท

Olivier Ravard <olivier.ravard@novagrid.com> wrote: