[Framework-Team] Re: A short update on performance

Alec Mitchell apm13 at columbia.edu
Wed Mar 7 15:52:08 UTC 2007

On 3/7/07, Rocky <rocky at serverzen.com> wrote:
> On Mar 6, 9:05 am, Wichert Akkerman <wich... at wiggy.net> wrote:
> > Previously Rocky Burt wrote:
> > > On Mar 6, 4:52 am, "Alexander Limi" <l... at plone.org> 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.


More information about the Framework-Team mailing list