int, float and string...

[Mike C. Fletcher]

See object.h in the Python source code.  Basically, Python objects 
(PyObjects) are a C structure with book-keeping information (what is 
your class/type, and your reference count) + the actual data of the 
object.    Depending on the object type, that can be anywhere from 
(minimum) 8 bytes to 8+x for every object.

For ints, it's 8+4 (see intobject.h in Python source code), so 12 bytes, 
only 4 of which are data.

For doubles, it's 8+8, so 16 bytes, only a 33% increase in size over ints.

However, each object you're storing/accessing is also being held as a 
reference in another list/object (another 4 bytes for a pointer), the 
total becomes 16 and 20 bytes respectively, only a 25% increase between 
them, with 75% and 60% of the memory being Python object overhead.

BTW, I'm not a C person, so I may be mis-calculating some of those 
values, basic principle still applies: don't worry about differentiating 
between int and float based on storage concerns save when using huge 
numbers of them (preferably in Numeric arrays).

BTW2, storing two references to the _same_ int or float object only adds 
4 bytes to your memory overhead (i.e. references are cheap), so if you 
had a huge set of identical values, using references to the same object 
(not just objects with the same value) might save you significant memory 
(this is done automatically for ints from -1 to 100 in Python 2.2 if I'm 
not mistaken).  Still, this is probably premature optimisation unless 
you actually find yourself running out of memory.

HTH,
Mike

Shagshag13 wrote:
> "Mike C. Fletcher" <mcfletch at rogers.com> a écrit dans le message de news: mailman.1023206585.1785.python-list at python.org...
...
>>machines if I recall correctly), but the overhead of Python objects is
>>huge compared to the size of the actual data, so don't worry about it
>>unless you're using Numeric Python and slogging around huge arrays of
>>numbers (where worrying about it might actually save you time).
> 
> 
> Thanks again for your replies !
> 
> Where could i go to see and understand what you call "overhead of
> Python objects" ?
> 
> thanks,
> 
> s13.
> 
> 
> 


-- 
_______________________________________
   Mike C. Fletcher
   http://members.rogers.com/mcfletch/