3 ms·
Something huge in here in case you missed it: "To reduce memory usage, the garbage collector will now clear internal free lists when garbage-collecting the hig
by wesm 18y ago
Something huge in here in case you missed it:
"To reduce memory usage, the garbage collector will now clear internal free lists when garbage-collecting the highest generation of objects. This may return memory to the operating system sooner."
For someone building long running processes or loading data generating millions of unique ints or floats over and over, this is major (though still hard to believe it was ever an issue).
- neilc 18y agoI'm not sure I understand why this is "huge." If the working set of the program is stable over time (or slowly growing), it seems like this isn't a significant win: it's only a win when the working set shrinks, and this change allows the freed memory to be returned to the OS more promptly. Your examples of "long running processes" or "generating millions of unique ints/floats" wouldn't necessarily qualify: ISTM that the normal generational GC should handle both those cases fine. Am I missing something?
- jackdied 18y agoLong story short: CPython uses a custom memory allocator on top of the OS malloc because some mallocs are really bad and python knows more about it's memory usage patterns than the OS. The newer CPython allocator plays better with popular OS's so that repeatedly newing and freeing lots of objects is more likely to return memory to the system. The old behavior didn't effect server sized systems and typical workloads but it did piss off some embedded apps.