maximum length of a list & tuple

[Josiah Carlson]

> Actually, unless I'm mistaken that stores only one integer, and a whole
> lot of references to it...  which are just pointers (4 bytes each).
> 
> The technique is probably flawed in other ways, however, as it
> is likely subject to memory fragmentation and other problems.

You can't just store the integer.  How would you differentiate between 
an integer in a list and a pointer?  Answer: you must use PyIntObjects. 
  Use the source.

According to intobject.c, intobject.h and object.h, the structure of 
every intobject (after the macros have been expanded) is as follows:

typedef struct {
     int ob_refcnt;
     _typeobject *ob_type;
     long ob_ival;
} PyIntObject;

The size of each of those on a 32 bit machine is 4 bytes, plus the 
pointer from the list (another 4 bytes), which leaves us with a total of 
16 bytes per integer object in the list.

Checking the memory usage of Python before and after the creation of 1 
million integer list, I get a /very/ consistant ~16 bytes per.  That 
would be 12 bytes for the object, and 4 bytes for each pointer in the 
list.  There is some additional overhead that you'd notice in 
intobject.c and/or intobject.h, but yeah.  Generally 16 bytes per integer.

As for memory fragmentation, considering how memory paging and 
segmentation works, that's all underlying stuff that the OS deals with. 
  I could go on as to why it doesn't matter in this case (considering 
the large mallocs necessary for the creation of large lists), but I'll 
leave that as an exercise to the reader.


Again, from the source, 12 bytes for the object, 4 bytes for the pointer 
in the list, total of 16 bytes per intobject in a list.

  - Josiah