memory leak with large list??

Bengt Richter bokr at oz.net
Sun Jan 26 16:11:40 EST 2003


On Sun, 26 Jan 2003 02:39:43 -0500, "Terry Reedy" <tjreedy at udel.edu> wrote:

>> > >Each object has at least a pointer to the object's type object,
>and a
>> > >refcount, for at least 8 bytes of overhead.  So a float object
>consumes at
>> > >least 16 bytes.
>> > Why do you need to duplicate the type pointer for all those? I.e.,
>if
>> > you allocated space in decent-size arrays of object
>representations without
>> > type pointer, and just reserved a header slot in front of the
>array, [snip]
>
>Because in Python, each object is a separate object, and because lists
>are heterogeneous.  Anyone who wants to work with 12 mil floats should
>almost certainly be using Numerical Python, which does have homegenous
>arrays of native floats (8 bytes per) along with C functions to do
>most common 'base' computatons.
>
I agree about using Numerical Python and an array of native floats for
12 mil floats, as you describe, but I don't think the fact that lists
"are heterogenous" is a real reason to need per-object type pointers
for all types of objects.

A list doesn't care where the objects it refers to are stored, so e.g.,
floats could be put in floats-only areas, and others could be put in
mixed-areas, and you'd figure type by figuring out from the address first
what kind of area the thing is in, and then if it's a float-only area,
you know right then you've got a float, and if its mixed, you go to the
object representation for type info.

Small lists and tuples could themselves be allocated in specialized areas
with some space savings, since they are homogeneous in themselves -- i.e.,
they don't actually have objects embedded, just references to objects.

But Tim is right, all in all it's usually easier to buy memory. And a simple
consistent way of doing things is worth a _lot_, which today's memory prices
allow. (I just got my space-saving reflexes when 4k of 300ns memory cost
more than all the PC's I've owned put together ;-)

Regards,
Bengt Richter




More information about the Python-list mailing list