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

Justizin justizin at siggraph.org
Sun Dec 10 15:38:30 UTC 2006


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
>

Bravo Martin, this is certainly a step in the right direction.  It's
easier to optimize than to start from scratch, so I imagine this will
get a little faster over time, and it sounds acceptable now.

> > 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. :)
>
> +1
>
> Martin
>

+1 from me as well, esp. wrt the ContentHistory / auditing in Mike
Pelletier's thread..

-- 
Justizin, Independent Interactivity Architect
ACM SIGGRAPH SysMgr, Reporter
http://www.siggraph.org/




More information about the Framework-Team mailing list