[Framework-Team] Re: [Plone-developers] Revisited: Some preliminary Plone 3.0 profiling results

Alec Mitchell apm13 at columbia.edu
Mon Dec 11 07:19:03 UTC 2006


On 12/10/06, Justizin <justizin at siggraph.org> wrote:
> On 12/10/06, Martin Aspeli <optilude at gmx.net> wrote:
> > Alexander Limi wrote:
> > > Breakdown of document_view shows (same order/units as above):
> > >>> path: plone_view/globalize       0.232   10  0.0232
> > >> path: plone_view/globalize      0.4314  10     0.04314
> > >
> > > path: plone_view/globalize          0.3136  10  0.03136
> > >
> > > Seems to have speeded up globalize a bit too, but still slower than my
> > > initial benchmark (although I think it does more now).
> >
> > The only additional thing it does is to calculate hash keys. It works
> > like this:
> >
> >   - globalize() defers to the views in plone.app.layout.globals,
> > plone_context_state and plone_portal_state.
> >
> >   - these views have various methods (most of which are called in
> > globalize()) which calculate values (previously calculated in
> > globalize()); the methods are memoized in the request. Thus, they are
> > only calculated the first time they are called and then stored in a
> > cache bound to the request.
> >
> >   - The cache is keyed on a hash (using the Python hash()) function of a
> > tuple that includes the context (if applicable), the view class name,
> > the method name and the arguments to the method (if any). I don't know
> > how expensive this call is, but it's the only thing I can think of that
> > would be slower (there are also three view lookups in globalize(), using
> > getMultiAdapter(), but I doubt they are the source of the slow-down).
> >
> >   - On subsequent calls to these methods in the plone.app.layout.globals
> > views, the cache key is recalculated and the value looked up in the
> > cache, if possible
> >
> > If anyone can suggest a faster, but still reliable, key, the code is in
> > http://svn.plone.org/svn/plone/plone.memoize/trunk/plone/memoize/view.py
> >
>
> So, I was poking around this evening trying to decide where to go wrt
> PageCacheManager and MemcachedManager, and I came across:
>
>   zope.app.cache.ram.py
>
> RAMCache in Zope3 is not thread-specific, and this code is in Zope 2.10.
>
> Based on the cache keys you are using zope.app.cache.ram.RAMCache and
> MemcachedManager should work properly, possibly giving increased
> performance.

This code isn't about a RAMCache which lives across threads and
requests, but is a short-lived cache which is bound to a particular
request.  It's purpose is to make multiple calls to the same
methods/attributes in a given request use the same data, e.g. to
relpace the elemts in global_defines (now @@plone/globalize) with a
more general, transparent, and reusable way of making potentially
expensive calls repeatable for a given request.  It would certainly be
possible to use a RAMCache for this but it would probably be overkill,
simply because it would be need to be keyed in a very general way (per
user, per context, per view, possibly per time of last content change
for navigation related methods).  In other words, if we were using a
more general cache we'd need to use a much different and more complex
set of keys.  Of course, these cache decorators can easily be
rewritten at any time to use a different storage mechanism if that
turns out to be desirable, probably with no changes needed to code
that makes use of them.

Alec




More information about the Framework-Team mailing list