[Tim] >> - For truly effective RAM releasing, we would almost certainly need to >> make major changes, to release RAM at an OS page level. 256K arenas >> were already too fat a granularity.
[also Tim] > We can approximate that closely right now by using 4K pools _and_ 4K > arenas: one pool per arena, and mmap()/munmap() are then called on > one page at a time. Sorry about this: there was another exceedingly subtle "there's more than one pool in an arena" assumption in the code, which didn't cause anything to fail, but did cause it to hold on to empty arenas in some cases. Repaired that, and then: > For memcrunch.py, using 200x the original initial objects, this works > quite well! > ... > So, at the end, space utilization is over 90%: > > 1,968,234,336 / 2,165,366,784 = 0.90896117 Which changed to the slightly better: 1,968,235,360 / 2,143,465,472 = 0.91824916 > OTOH, an even nastier version of the other program I posted isn't > helped much at all, ending like so after phase 10: > ... > 232,861,440 / 4,073,746,432 = 0.0571615 And that one enjoyed a relatively huge improvement, to: 232,861,440 / 2,334,990,336 = 0.09972694 But none of that changes any of the bottom-level observations or speculations. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/WX5CJODDLQIQAYJRYY2FWPUPVR725SWV/
