On Sat, Nov 28, 2009 at 12:14 PM, Martijn Faassen <faas...@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 _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org 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 )
