> Way back in TT1 we compiled the templates down to an optree which was
> evaluated at runtime. However, I didn't make any real attempt to
> optimise it (or didn't know how to at the time) and it ran kinda
> sluggish. When we switched to the compiled Perl for TT2 we got a big
> boost in speed. But looking at your numbers, it's obviously that the
> optree approach can be just as fast if not faster if done right.
The optree isn't faster at everything. I can't beat large while loops and
foreach loops that are running in native perl.
My optimized execution may also be getting some speed benefit from my
"provider" system. It is possible that even on the cached in-memory
templates some of the perceived speed is coming because CET is not doing
something that TT is. Combining the CET optree with the TT provider may
end up in a net decrease of speed (nobody has tried it so nobody knows).
> The TT3 parser is split into the classic front/back end model. The
> front end generates an optree (similar but slightly different to yours),
> the back end then walks the tree to generate Perl code (or Javascript,
> Ruby, C, etc). The TT2 parse does a similar kind of thing, but it's all
> internalised within the YAPP grammar and is difficult to mess with. TT3
> better defines the role of the optree, makes it more accessible and
> generalises both the front and backs end so you can plug in your own
> parser or code generator.
>
> So we could easily plug in a different back end which effectively passes
> the optree back through (with a little bit of finalising along the way)
> for runtime evaluation.
>
> In short, we should be able to make this kinda thing work in TT3, no
> problem.
Neat.
> In a similar vein, the TT3 parser creates one big structured expression
> for the parse tree. The general form is:
>
> [ type, @args ]
>
> Or for a concrete example:
>
> x + 3 => [add => [variable => 'x'], [number => 3]]
Sort of funny - but I wrote a templating system that we use at my current
company (I wrote it 4 years ago - it grew to eventually have many TT style
features). The language contructs are all in that sort of notation (operator
first). It is very fast - faster than most of the engines on CPAN, but it
also has too much internal code and odd exceptions and poor handling of
nested data structure and warts and junk that I still prefer using TT syntax.
TT syntax is much easier to understand.
That language looks like:
This is printed.
[if [&& form.a form.b] q{
This is printed if form.a and form.b are true.
} else q{
This is not printed if they're true.
}]
[var a.n = [+ [* 2 3] [/ 5 6] [- 8 7]]]
> Anyway, if you can send me a link to the code I'd love to take a good
> look through it and see what I can draw inspiration or borrow code from.
> There's some bits of the TT3 parser that I'm still not happy with, but
> this could give me the last big push!
TT3 will be great. I also can't wait for Perl6. Because then the parsing can
become a grammar that outputs the tree. That will be very nice. Ah - one
can dream. Sigh.
Paul
PS - I'll include the CGI::Ex::Template module in some follow up code - I
guess it would be better to let many eyes have a look at it - even before its
initial release.
_______________________________________________
templates mailing list
[email protected]
http://lists.template-toolkit.org/mailman/listinfo/templates
