On 3/7/07, Rocky [EMAIL PROTECTED] wrote:
On Mar 6, 9:05 am, Wichert Akkerman [EMAIL PROTECTED] wrote:
Previously Rocky Burt wrote:
On Mar 6, 4:52 am, Alexander Limi [EMAIL PROTECTED] wrote:
- TypesTool in CMFCore - adding the threadlocal cache makes that part
close to three times as fast, even after the recent Zope 2.10 fix. I think
we should do this, as we already subclass TypesTool, and adding the
optimization cache here is a quick win.
Yeah, theoretically the change should go into CMF's TypesTool and not
hours. Perhaps if someone has time (not me at the moment) we could
submit a patch to the CMF group we just override in Plone.
Why not optimise this in Zope? That is where the bottleneck is.
Making it work efficiently in zope is one thing. Caching it to go
beyond imho is just not something Zope should be responsible for.
From Zope's standpoint the call only takes a few milliseconds and is
only called a few times. It's CMF that is calling it a zillion times
(why?). So it is CMF that should avoid making so many calls... if
that means caching in CMF, so be it.
I'm 100% with rocky here, the major inefficiency he introduced is
resolved. Checking the availability of particular factories has
always been one of our weak points, and ironically the huge slowdown
he introduced made it clear how we can do even better. The
fundamental issue is not that product lookup is slow in zope, but that
CMF uses the Product lookup mechanism as a registry without any sort
of caching. This is quite easy to fix either in Plone or in the CMF
depending on the timeframe we need it merged in for. I initially used
a thread local for safety because I wasn't entirely sure what sorts of
things would end up in this cache. However, by now it's pretty clear
to me that an instance level cache should be perfectly safe, which
should be a little faster yet.
Alec
___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
