On Sat, Nov 28, 2009 at 12:14 PM, Martijn Faassen <faassen@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