Saturday, December 13

Plone trunk versus kcachegrind

David Glick reminded me a while back of a visualization tool for profiling data called kcachegrind. After trying to optimize Plone trunk based on simple Python profile data for a while, a more advanced analyzing tool was desperately needed.

In order to convert the normal Python profiling output into a format readable by kcachegrind, you need to run a script called pyprof2calltree over it. The publically available version seems to be broken in some ways but David took on the challenge and sent me a fixed version.

After getting familiar with the tool and poking at Plone trunk for a bit, I was able to identify a couple of more places, which I hadn't found so far in my optimization attempts. So at the end of day two of the Plone Performance Sprint 2008 happening in Bristol right now, I got some notable results. Compared to the last results I posted three weeks ago, everything but edit pages have seen another 50% speed increase. Thank you David!



One of the changes was inside ResourceRegistries and can be readily applied in Plone 3.x as well. It saves about 10ms per request in a default site. All other changes still revolve around optimized actions handling. The amount of speed increase you can get by rather simple and straightforward changes still amazes me. Stay tuned for more.

Update:

This morning I found another problem with content type icon expressions being recompiled on every page load. I updated the graph with the new results: We got up from 24 requests/s to 27 requests/s ... I like it :)

Update 2:

I found a bit more places to optimize and took a look at Archetypes edit screens in particular. Updated graph is above, we are now officially three times faster than Plone 3.2 and have reached the magical 30 requests / sec number.

Saturday, December 6

Plone versus Python 3

Python 3 final has been released. What does this mean for Plone and how could a roadmap for adoption look like?

I peaked into my crystal ball and came up with a couple of statements that reflect my own personal opinion. So here is one possible scenario for the future:
  • The Plone 3 series will see major releases up until 3.4 or 3.5 in a roughly six to nine month iteration and stretch into 2010.
  • Plone 3 will see support for Python 2.5 and 2.6 in Plone 3.4 while staying backwards compatible with Python 2.4.
  • Plone 4 final will be released in early 2010.
  • Plone 4 will recommend Python 2.6 and might be backward compatible with 2.5.
  • Plone 4 will see multiple 4.x releases in the same way 3.x did. These will continue throughout 2010 and 2011.
  • If a Python 2.7 is released during the lifetime of Plone 4.x, support for it will be added.
  • Plone 5 will run on Python 3 and see a release in 2011 or 2012.
This is only one possible scenario. What do you think?