[Zope] Problem: performance of retrieving properties from objects...

[Casey Duncan]

Yes, there will most certainly be a totally different concept of 
properties in Zope 3. But you are right that changing them in Zope2 
would be too painful and break too much legacy code 8^(.

If you are looking for a way to store large quantities of mapped values, 
It would not be hard to implement a method using dictionaries or BTrees. 
You could even write it in such a way that it was compatible with the 
existing propertymanager/propertysheets interface and thus could use the 
  same managment interface and methods.

-Casey

Dieter Maurer wrote:
> Antwan Reijnen writes:
>  > ... accessing properties with "getProperty" and
>  > "propertyItems"....
>  > Agree, but consider this: when I retrieve a fixed set of data, on propertysheets with varying number of properties (N), the fetchprocedure takes more time when N increases... Why should propertysheet.getProperty('aProperty') take longer on a larger propertysheet?
> 
> 
> Currently, PropertySheets store their properties directly as attributes
> of the parent (i.e. the ZClass instance). Because of this,
> "getProperty" cannot relay on an "AttributeError" to see that
> "id" is really a property. It, therefore, calls "hasProperty"
> and then uses "getattr" on the parent.
> 
> Properties have not been conceived as a mass storage concept.
> Therefore, the properties description is stored as a tuple.
> "hasProperty" iterates over the tuple and checks for the "id".
> This is linear in the size of the tuple.

[snip]

>   There may be new PropertySheets in Zope 3, that do it differently.
>   But, for backward compatibility, the current sheets will almost
>   surely continue to work as you see now.
> 
> 
> Dieter