| 47 | |
| 48 | == Ideas for improving the performance == |
| 49 | |
| 50 | In 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 ? |
| 57 | The 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 | |
| 59 | It 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 | |
| 67 | It 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 | |
| 69 | But 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) ? |
| 73 | Not 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 | |
| 77 | Stream 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 | }}} |