[Framework-Team] Re: Revisited: Some preliminary Plone 3.0 profiling results
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
- 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