On Mon, Jul 01, 2002 at 03:49:07PM -0300, Sidnei da Silva wrote:
On Seg 01 Jul 2002 15:26, Jim Fulton wrote: | I'll add that the current ZPT implementation is too slow | (thanks to recent DTML speedups ;). | | ZPT needs to be as fast as or faster than DTML. It would be | great if it was cleaner and more pluggable.
I remember that i had the same concern when discussing this with lalo, and he told me that this should be faster, as TAL-Current stores a binary representation of the XML Parsed source, and his version is based on PAX, and this would not need to be pre-compiled and stored. Unfortunately I cannot give more information as this explanation seemed fine to me at that time.
Our original prototypes of ZPT stored a DOM tree in the ZODB, so they only really parsed the source when it was updated. When the stuff was rewritten for optimization, DOM was done away with in favour of TAL "bytecode" which, for some reason, isn't stored persistently. I asked once, and I seem to remember the answer was "it doesn't pickle well". Well, Alt-TAL is an experiment to see how fast a pluggable and readable version of TAL could be. My first step was to construct a "bytecode" that is pickleable and is not TAL-specific. This is PAX. I didn't yet announce PAX anywhere as it is evolving fast to meet the needs of Alt-TAL, but I plan to make it a package in its own right in the near future. In Alt-TAL, rendering TAL is a "PAX Transform". This dawned on me as a result of a comment by Leo Almeida that TAL could probably be implemented as a XSLT sheet. Alt-TAL currently only implements the tal: namespace, and tal:on-error is missing because it implies an exception-handling infrastructure which I didn't yet even design. So, the reason I didn't announce Alt-TAL was that it was so incomplete. But in my tests (and I run tests on a very old ppc machine, so that I may get a visual feel for the speed differences), the few input templates that already pass, pass faster than with the original TAL. Of course this experience has a long way to go. I need tal:on-error, then all metal: stuff, then make a version of PageTemplate that uses Alt-TAL (originally I planned Alt-TAL to be a drop-in replacement, but that would impact performance very badly so I gave up), then benchmark and optimize and benchmark and rinse and repeat. In a very extreme case, PAX (or perhaps PAX transform) can be optimized into C or Pyrex. As it has a lot of "for" loops, I assume this would be a gain. Of course, as my design skills are stronger than my coding skills, and as my optimizing skills are very very weak [;-)], I invite anyone interested in this experience to join in. []s, |alo +---- -- It doesn't bother me that people say things like "you'll never get anywhere with this attitude". In a few decades, it will make a good paragraph in my biography. You know, for a laugh. -- http://www.laranja.org/ mailto:lalo@laranja.org pgp key: http://www.laranja.org/pessoal/pgp Eu jogo RPG! (I play RPG) http://www.eujogorpg.com.br/ Python Foundry Guide http://www.sf.net/foundry/python-foundry/