This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Memory leaks?
Type: Stage:
Components: None Versions:
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: rhettinger, romanrm, tim.peters
Priority: normal Keywords:

Created on 2004-10-16 22:49 by romanrm, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (4)
msg22707 - (view) Author: Roman Mamedov (romanrm) Date: 2004-10-16 22:49
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?
msg22708 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2004-10-17 00:04
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.
msg22709 - (view) Author: Roman Mamedov (romanrm) Date: 2004-10-17 18:50
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.
msg22710 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2004-12-23 19:39
Logged In: YES 
user_id=80475

Closing because there is no bug here.

You're welcome to submit a patch attempting to improve 
memory utilization while keeping int/float performance 
constant.
History
Date User Action Args
2022-04-11 14:56:07adminsetgithub: 41029
2004-10-16 22:49:41romanrmcreate