[Zope-dev] implementing zope.component 4.0
Hanno Schlichting
hanno at hannosch.eu
Sat Nov 28 08:32:50 EST 2009
On Sat, Nov 28, 2009 at 12:14 PM, Martijn Faassen
<faassen at startifact.com> 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
More information about the Zope-Dev
mailing list