Previously Andreas Jung wrote:
> --On 4. März 2007 13:57:23 +0100 Wichert Akkerman <[EMAIL PROTECTED]>
> >I'm forwarding a message from limi here, since it makes much more sense
> >here than it does on plone-developers. To summarize it: while analying
> >performance of the Plone 3 codebase they noticed a lot of time was spent
> >trying to figure out which types could be added at a location. Part of
> >that logic uses the TypesTool _queryFactoryMethod function, which goes
> >through the dispatcher to get to the factory method for a type, which is
> >apparently very slow in Zope 2.10, and much faster in Zope 2.9.
> Any idea why the code is different between 2.9 and 2.10?
Rocky modified it in changeset 67869 to be able to support external
methods outside of products. The problem with the new code is that it
imports all products to figure out some of their details. So for every
factory dispatcher access we now have an import for each product, which
means lots of filesystem accesses and python interpreter work being
> >They came up with http://paste.plone.org/13211 which is an imho somewhat
> >evil approach which introduces a thread-local cache for
> >App.FactoryDispatcher._product_packages. As described below the speedup
> >as a result of that is huge.
> I would not be opposed against such a speedup patch as long as it does
> not raise other problems. However I don't know App.* enough to be evaluate
> the patch.
http://paste.plone.org/13217 should do the trick. It makes
_product_packages cache its result using the list of products in
Control_Panel as a cache key. That makes sure that removing or adding
products there will not result in stale data being returned by the
Wichert Akkerman <[EMAIL PROTECTED]> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests