[ python-Bugs-1048495 ] Memory leaks?

[SourceForge.net]

Bugs item #1048495, was opened at 2004-10-17 04:49
Message generated for change (Comment added) made by romanrm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1048495&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Roman Mamedov (romanrm)
Assigned to: Nobody/Anonymous (nobody)
Summary: Memory leaks?

Initial Comment:
Open python command-line interpreter. Enter:

>>> a = range (10000000)

Observe Python memory usage. 20 Mb real, 159 Mb virtual memory here(I'm on windows). Enter:

>>> a = 0

Observe memory usage again. 120 mb real/120 mb virtual. OK, this is a garbage collected language, lets try to garbage-collect.

>>> import gc
>>> gc.collect()
0

That didn't help. The memory usage is still at 120/120.

So, the question is, when that "range" object will get deleted, or how to do delete it manually? Why garbage collection doesn't get rid of "orphaned" objects?

Any comments?

----------------------------------------------------------------------

>Comment By: Roman Mamedov (romanrm)
Date: 2004-10-18 00:50

Message:
Logged In: YES 
user_id=943452

Thank you very much for a detailed explaination.

In my opinion, this issue deserves more attention and consideration. There's a trend to create not just simple  fire-off/throw-away scripts, but complex, long-running, GUI software in Python(as well as in other scripting/VM  languages), and this tradeoff could make memory usage unnecessary high in not-so-rare usage patterns. That  way, a split-second gain caused by having immortal integers could easily be eaten by VM trashing due to  overconsumption of memory. I believe that comparable integer/float performance can be attained even without having these types as infinitely-immortal.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-10-17 06:04

Message:
Logged In: YES 
user_id=31435

range() constructs a list.  The list takes 4 bytes/entry, so 
you get about 40MB reclaimed when the list goes away.  The 
space for integer objects happens to be immortal, though, 
and the approximately 12 bytes per integer doesn't go away.  
Space for floats is also immortal, BTW.

There aren't easy resolutions.  For example, the caching of 
space for integer objects in a dedicated internal int freelist 
speeds many programs.  And if Python didn't do special 
memory allocation for ints, malloc overhead would probably 
boost the memory burden in your example to 16 bytes/int.

So there are tradeoffs.  Note that xrange() can usually be 
used instead to create one integer at a time (instead of 
creating 10 million simultaneously).  Then the memory burden 
is trivial.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1048495&group_id=5470