Hi,

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


_______________________________________________
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Reply via email to