On Wed, 2005-12-28 at 18:57 -0500, Raymond Hettinger wrote: [...] > What could be done is to add a test for excess dummy entries and trigger > a periodic resize operation. That would make the memory available for > other parts of the currently running script and possibly available for > the O/S. > > The downside is slowing down a fine-grained operation like pop(). For > dictionaries, this wasn't considered worth it. For sets, I made the > same design decision. It wasn't an accident. I don't plan on changing > that decision unless we find a body of real world code that would be > better-off with more frequent re-sizing.
I don't think it will ever be worth it. Re-allocations that grow are expensive, as they often need to move the entire contents from the old small allocation to the new larger allocation. Re-allocations that shrink can also be expensive, or at the least increase heap fragmentation. So you want to avoid re-allocations whenever possible. The ideal size for any container is "as big as it needs to be". The best heuristic for this is probably "as big as it's ever been, or if it just got bigger than that, assume it's half way through growing". which is what Python currently does. Without some sort of fancy overkill size hinting or history tracking, that's probably as good a heuristic as you can get. -- Donovan Baarda <[EMAIL PROTECTED]> http://minkirri.apana.org.au/~abo/ _______________________________________________ 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
