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.
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:[EMAIL PROTECTED]
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/
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -