Re: implementing zope.component 4.0

On Sat, Nov 28, 2009 at 12:14 PM, Martijn Faassen
<[email protected]> wrote:
> Adam GROSZER wrote:
>> I had a feeling that adapter lookup can be alone slowish with lots of
>> registrations.
>> We had a large project that was cut in half and the z3c.form UI, which
>> is rather heavily adaptation based got a boost after that.

What is a "large project" in your case? Just as an example here's the
"size" of the global registry in a typical Plone project:

 >>> getGlobalSiteManager()
 <BaseGlobalComponents base>
 >>> len(getGlobalSiteManager()._utility_registrations)
 1091
 >>> len(getGlobalSiteManager()._adapter_registrations)
 1283
 >>> len(getGlobalSiteManager()._handler_registrations)
 139
 >>> len(getGlobalSiteManager()._subscription_registrations)
 3

> Interesting. It'd be interesting to do some experiments with this. Could
> you perhaps look into writing some kind of stress-test script?

I haven't done any real performance measurements but the various
zope.interface/component API's are among the top of every profile run
I do in Plone.

To me it looks like checking if an interface is provided by a context
is non-trivial and the main bottleneck in our case. The classes
underlying our typical contexts are pretty fat classes with a long
inheritance chain contributing dozens of interfaces.

The actual registry lookups seem to be rather fast, they should be
essentially dict lookups, which perform well with a dict size of just
about 1000.

On the other hand I noticed that z3c.form and it's use of the ZCA is
indeed much slower than stitching forms together via ZPT macros as
done for example by Archetypes.

Hanno
_______________________________________________
Zope-Dev maillist  -  [email protected]
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )