[Framework-Team] A short update on performance
limi at plone.org
Tue Mar 6 07:52:56 UTC 2007
Did some additional profiling today - comparing 3.0 to 2.5, testing
Rocky's fix for the issue we found at the optimization sprint, etc. All
timings are for 10 calls.
- Rocky's fix to Zope 2.10 fixes the worst of the performance penalty, but
calling contentmenu.pt still takes 0.76s with his changes — the
threadlocal cache in TypesTool got it down to 0.27s (with 2.10.2's broken
code, it took a ridiculous 6.38s).
- Plone 3 is a tiny bit faster than 2.5 for rendering the document view
(3.07s vs 3.47s). We should be able to do better than this. ;)
- Rendering the edit page is slower in 3.0 — predictably, since it does a
lot more now. It takes 6.29s to render it after the optimizations Hanno &
co did (8.96s before). As a comparison, Plone 2.5 took 4.54s, but only
rendered a small subset of the widgets that are there now.
Targets for optimization:
- column.pt (the view needs to be profiled properly to see if there's
scary stuff going on). It takes about 0.8s to call it right now, although
none of the time is spent in the template itself.
- 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.
- plone_view/globalize in views is the most expensive call we do by an
order of magnitude. On the average view template, globalize takes up
0.52s, and the next most expensive call is
mtool.getMemberInfo(user.getId()), which takes 0.04 seconds (ie. not worth
optimizing). If we can make globalize faster, everyone wins. :)
Alexander Limi · http://limi.net
More information about the Framework-Team