int, float and string...
Mike C. Fletcher
mcfletch at rogers.com
Tue Jun 4 13:44:51 EDT 2002
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.
> "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" ?
Mike C. Fletcher
More information about the Python-list