Edgewall Software

Changes between Version 37 and Version 38 of GenshiPerformance


Ignore:
Timestamp:
May 13, 2011, 12:56:15 AM (13 years ago)
Author:
cboos
Comment:

copied some notes from Christopher about possible performance enhancements

Legend:

Unmodified
Added
Removed
Modified
  • GenshiPerformance

    v37 v38  
    4545|| Genshi || 2.89 ms || ||
    4646|| [http://kid-templating.org/ Kid] || 6.93 ms || ||
     47
     48== Ideas for improving the performance ==
     49
     50In a [http://groups.google.com/group/trac-dev/msg/fe3bfd51a880a3e7 mail on Trac-dev] in April 2010, Christopher Lenz wrote the following, in reply to Eirik Schwenke:
     51{{{
     52#!div style="margin: 1em 2em; border: 2px solid #ccc"
     53> Anyway, I think there are three seperate issues, that all warrant discussion:
     54> >
     55> > a) Is the speed of genshi doomed due to genshis design? And if so,
     56> >    should we for *speed reasons* give up on genshi ?
     57The current design is inefficient in a number of ways. The whole design choice that everything is streamed through the pipeline event by event (SAX-style) using Python generators has proved to be rather poor. That match templates are processed at render time makes their use quite expensive, and it certainly doesn't scale to a larger number of match templates.
     58
     59It would be possible to move Genshi towards a more efficient implementation by:
     60
     61 * Dropping support for dynamic XInclude tags, i.e. Genshi would need to know what gets included at parse time.
     62 * Moving match template processing to the parsing stage (aka static match templates); or alternatively, drop the match template idea altogether and move to the more conventional model of template inheritance where the master predefines slots that can be filled.
     63 * Compiling templates to Python bytecode.
     64 * Providing a fragment caching system.
     65 * Etc.
     66
     67It would still not be in the same league as highly optimized text template engine such as Mako or Jinja2, but I think it would be totally usable. As a point of reference, Genshi trunk is in some cases actually faster than Django templates in raw throughput when you don't use things like match templates (last time I tested at least), and lots of sites use Django templates. I think that doing the above changes would make Genshi consistently faster than Django templates (at least the current implementation).
     68
     69But those changes also require a lot of work, and would obviously take away some features people (including Trac and Trac plugins) may have been relying on. It'd basically be Genshi2 ;)
     70
     71> > c) Does genshi's stream-filters provide enough of an advandage
     72> >    to push for b) over a) ?
     73Not sure. Stream filtering is used for a couple things, most importantly form filling and localization. Removing stream filtering leaves two alternative ways to achieve these (and similar) tasks:
     74 * post-process the generated output (parse/transform)
     75 * take care of everything right in the template, i.e. manually fill in form values, gettext() all strings, etc.
     76
     77Stream filters are nice in that they let you implement "cross-cutting concerns" outside of the templates, and doesn't require a post-processing stage. Whether that's worth the cost I don't know.
     78}}}