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

[Dieter Maurer]

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.

With current Zope, your most efficient way to access a property
is "getattr" on the ZClass instance. Of course, this requires
that you know what you access is really a property of the object.
If not, you may get an acquired non-property.


The PropertySheet implementers have been aware that the current
storage mechanism (abusing the parent for storage) is a break
in the PropertySheet's concept (different PropertySheets should provide
separate namespaces; currently, they are couple by the parents
namespace). Therefore, they documented that accessing properties
via "getattr" from the parent may be removed in future versions.

  Personally, I do not expect this to happen, as it will
  break almost all ZClass applications.

  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