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

Martin Aspeli optilude at gmx.net
Sun Dec 10 13:07:50 UTC 2006

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 

> I guess the next step is to move all the versioning and publishing 
> history to a separate tab, combine them into the same overview, and 
> rename the tab from Versions to History. Then we'll have a better 
> impression of what the logged-in view cost is. :)



More information about the Framework-Team mailing list