launchpad-dev team mailing list archive

[Gary Poster <gary.poster@xxxxxxxxxxxxx>]

Hi all.  If you are working with a page template that has to render a lot, and that seems to be bogged down in rendering, I suggest you look at using Chameleon to speed things up a bit.

It's easy to do in isolation.  It can slice a half second or so from tables that render 300 rows.  As such, it's not a wild win from a page performance perspective, but a reasonably nice one.

(It's an even nicer win for general efficiency of our application, but that's a different question.  https://dev.launchpad.net/LEP/Chameleon describes switching the entire app to Chameleon, and the history of the project.  That LEP is now entirely out of date, by the way: Chameleon is reimplemented now, almost certainly leading to a brand new "gotcha" list as well as a new implementation of the memcache directives.)

How to do it:

1) Find templates that do not use macros, or that only use macros internally (this is because a Chameleon use-macro can't use a standard ZPT define-macro).  (Alternatively, you could always separate out the part with the table/loops/whatever into a separate Chameleon-powered template on the view if you really wanted to, and insert it into the ZPT template as structure.)

2) In the zcml, rip out the "template="..."" part of the page directive.

3) On the view class, given "from z3c.pt.pagetemplate import ViewPageTemplateFile", add "template = ViewPageTemplateFile(...)".  (Replace the ellipsis in step 3 with the value of the ellipsis from step 2.)  (If you have no view class, make one, and set it up in the zcml as usual.)

4) Profit.

Note that the first time (per process) that you go to the view that has the template, you'll have to pay a compile cost.  There are ways around this, but they would introduce a new compile step in our build, and force some mildly deep thought about deployment issues.

Gary