Issue1048495
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.
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) * | 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) * | 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:07 | admin | set | github: 41029 |
2004-10-16 22:49:41 | romanrm | create |