[Fred L. Drake, Jr.] > Free'd weakref objects are stored in a free list, so it makes sense > that these are labelled potential leaks. > We could either give up using a free list for these, or we could > allocate blocks of these rather than allocating them individually. > The latter would allow still better performance and would reduce the > malloc overhead. -0. When we turn on pymalloc in 2.3, blocks will get allocated by magic, and more space-efficiently than you're going to do by hand (it bites one malloc overhead per 256KB). pymalloc will likely be a little slower than a wholly customized free list, but it will get all the memory benefit, and unlike type-specific free lists allows memory to be recycled across types as programs progress. > That change would be a higher risk than tossing the free list, and > tossing it would be a higher risk than keeping it this close to the > release. But we're probably far enough away that any of the options > (no free list, blocking allocation, and leaving it alone) are > manageable. There's another possibility: as float objects do, add a module xxx_fini() routine to clear the free list at shutdown.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4