[Greg Ewing] > Surely there's some compromise that would allow > recently-used ints to be kept around, but reclaimed > if memory becomes low?
Not without losing /something/ we currently enjoy. The current int scheme has theoretically optimal memory use too, consuming 12 bytes per int object on a 32-bit box. That's minimal, because the object's type pointer, refcount, and integer value each require 4 bytes on a 32-bit box. It does this by allocating "big blocks" and carving them into 12-byte slices itself. But as with any "big block" scheme, a live integer anywhere in a block prevents the entire block from being freed, and objects can't /move/ in CPython either (so, e.g., if a single live integer is keeping a big block alive, we can't move it into some other block). That's the same kind of problem obmalloc has with its "very big block" arenas, and for which only heuristic help was added (with considerable increase in complexity) for 2.5 (before 2.5, obmalloc never freed an arena, same as ints and floats never free their versions of big blocks). _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
