Peter Hansen <pe***@engcorp.com> wrote:
Alex Martelli wrote:
Claiming that you have to have all info in memory before a tuple can be
built is simply wrong -- your previous claim that the info had to be in
a list was even "wronger", sure, but that doesn't make your current
weaker claims correct in the least.
So, back in the original context here... would you agree that
use of a tuple is "quite realistic" (i.e. a technique that will
save significant amounts of memory) when "there is a huge amount
of static data that you need to access quickly"?
A list of N items over-allocates a bit more than 12% slots (N>>2+6 for
large N). As to whether that saving can be all that significant, I have
my doubts -- a typical list or tuple will uniquely hold a different
object per slot, and an object is way larger than a slot -- the saving
is only in slots, since the objects will be around anyway whether held
in a list or tuple. So the overall savings of memory should be a few
percent at most, excepting unlikely cases where many slots of the
container are referring to the same (relatively few) objects, and even
in the best case can't be more than 10% or so. I would not normally
call even 10% a "significant" amount of memory saving.
This has nothing to do with the issue of where you're keeping the data
before building the container, really. You could have plenty of memory
_at the time you're building the container_, towards the start of your
program, and yet be quite interested in having the long-lasting
container eat up as little memory as feasible, in order to leave memory
available for other uses later, in those crunch-times where you know
your program can end up memory-cramped. Unfortunately, the savings
available this way are not big, I believe.
Alex
