On Thu, Apr 8, 2010 at 12:38 PM, Christopher Lenz <[email protected]> wrote: > >> Anyway, I think there are three seperate issues, that all warrant discussion: >> >> a) Is the speed of genshi doomed due to genshis design? And if so, >> should we for *speed reasons* give up on genshi ? > > 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.
This should be documented - absolutely. I would vote for a Python conference talk describing the situation in great detail. This is a very good example of a unfortunate architectural design that proves that some good concepts are hard to be implemented. It should be documented, because the problems with such designs don't lie on the surface. Implementation for some concepts can consume too much resources, can be inefficient for extension, maintenance and may not scale. It would be nice to see analysis if these essential problems could be predicted from the beginning. What was required to be able to do so at that time? How should we probe our new ideas to see these problems? Genshi design resembled me XSLT. My experience with XML/XSLT proved that this technology is inefficient, it seems to have all the same problems, but I can't explain why, and that's bad, because some people continue dreaming about how powerful and beautiful XSLT is. I can't explain them why DocBook XSLT templates are bad without resorting to example that when PHP manual turned to 12Mb XML, it took me 8 hours and about 300Mb memory to compile it on 256Mb machine. I was debugging XSLT templates to add new feature to Extended CHM format. After this I ceased my work on xCHM. Now I like how Sphinx does docs for Python, but I have 4Gb machine with several cores, and it is fast. I can't say if it is easy to debug templates for Sphinx, but I know for sure that XSLT debug is a nightmare even now. It is fun to learn XML, XSLT, because nobody tell you about the complexity of debug, that writing such templates is one way only. It would be extremely interesting to know about Genshi mistakes, because such reports are rare. People do not like to talk about their mistakes. They like to share new ideas, perspective prototypes, but knowledge about mistakes is more valuable. I'd even say that such mistakes deserve a book. I can add some paragraphs to chapter about XSLT. =) > It would be possible to move Genshi towards a more efficient implementation > by: > > * Dropping support for dynamic XInclude tags, i.e. Genshi would need to know > what gets included at parse time. > * 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. > * Compiling templates to Python bytecode. > * Providing a fragment caching system. > * Etc. > > 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). It is a pity there is no testsuite to analyze features vs performance for various template engines using templating scenarious, examples and performance/memory metrics. > 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 ;) > >> c) Does genshi's stream-filters provide enough of an advandage >> to push for b) over a) ? > > 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: > * post-process the generated output (parse/transform) > * take care of everything right in the template, i.e. manually fill in form > values, gettext() all strings, etc. > > 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. That's why metrics with examples is needed. -- anatoly t. -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
