Any problems with *lots* of attributes?

[John Roth]

"Frank Millman" <frank at chagford.com> wrote in message
news:246a4e07.0402042327.5192034a at posting.google.com...
> > Frank Millman <frank at chagford.com> wrote:
> > >
> > >This is a question about the performance trade-off between two methods
> > >of storing data. One method is to create a separate attribute for each
> > >piece of data, and get/set the value according to its name. Another
> > >method is to create a list, and get/set the value according to its
> > >position in the list. In my limited tests, the first method is quicker.
>
> Aahz <aahz at pythoncraft.com> wrote:
> >
> > That doesn't make any sense.  While lists and dicts are both essentially
> > O(1) for access, the constant is larger for dicts.  Please show us your
> > testing code.
> >
> Code shown below, but here is a summary -
>
> print f.getval_from_attr()
> print f.getval_from_list()
> print f.setval_in_attr(1000)
> print f.setval_in_list(1000)
>
> Results, to 2 decimal places, are as follows -
>
> 0.32
> 0.45
> 0.34
> 0.44
>
> > OTOH, there's certainly nothing wrong with using dicts; they are the
> > single most fundamental Python data type after strings.  (All Python
> > name/attribute access is built on top of dicts.)
>
> This is exactly my point, but I may be misunderstanding how it works
> internally. If I have a class with 20 attributes, it will have a
> dictionary with 20 entries. If I have hundreds of instances of the
> class, do I end up with hundreds of dictionaries (or the equivalent
> internal structures), and if so, does this not lead to memory bloat?
> If I store the data in a list, there will only be one dictionary entry
> per instance. On the other hand, I suppose there must be some
> reference to each of the elements of each list, so maybe there is an
> equivalent overhead. Is this a valid concern, or am I worrying about
> nothing?

I believe the memory overhead for dictionaries is 4 times that for
lists on a per item basis, however both data structures allocate
extra space so that they don't have to reallocate too frequently
(a very expensive operation.)

>
> Thanks for your input. Test program is shown below.
>
> Frank