Python memory deallocate

Heiko Wundram me+python at modelnine.org
Thu May 11 09:54:58 EDT 2006


Am Donnerstag 11 Mai 2006 15:15 schrieb mariano.difelice at gmail.com:
> I MUST find a system which deallocate memory...
> Otherwise, my application crashes not hardly  it's arrived to
> break-point system

As was said before: as long as you keep a reference to an object, the object's 
storage _will not be_ reused by Python for any other objects (which is 
sensible, or would you like your object to be overwritten by other objects 
before you're done with them?). Besides, even if Python did free the memory 
that was used, the operating system wouldn't pick it up (in the general case) 
anyway (because of fragmentation issues), so Python keeping the memory in an 
internal free-list for new objects is a sensible choice the Python developers 
took here.

Basically, what I think is happening is that you are loading all images that 
you use for your program into memory at once, and these simply will eat up 
your memory until your program crashes (because Python can't know you no 
longer need them). As you keep a reference to the image (somewhere, 
someplace), del(eting) the reference in one scope isn't going to free the 
memory for Python (or PIL in this case) to reuse for the next image. An 
object is kept alive because of a memory leak inherent to your application.

This is a programming problem, not a Python problem. And, if you don't post 
any sources, we won't be able to help you much here, save to tell you to look 
closely where you create objects, and where you store them to.

PIL isn't known to have any memory leaks, by the way (AFAICT), just to confirm 
what I've written before, but the effbot should be of more help here...

--- Heiko.



More information about the Python-list mailing list