[Framework-Team] A short update on performance

Alexander Limi 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.

Notable findings:

- 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 mailing list