You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by sh...@isupportlive.com on 2000/06/08 09:52:52 UTC
Re: Template techniques
On Thu, Jun 08, 2000 at 01:48:40PM +0100, Matt Sergeant wrote:
> On Thu, 8 Jun 2000, Greg Cope wrote:
>
> > This may be veering off topic - but its been on my mind for a while now ....
> >
> > Apart from thanking Stas for his benchmark work, which I find very
> > interesting (does he sleep ;-) - this and few few others (benchmarks) have
> > all touched on the area of including mod_perl output within HTML. I have
> > always wonder what everyone else is doing on this front.
> >
> > I usually suck a template into memory (one long line) - usually done at
> > startup. I then create all the conent with either pushing onto an array, or
> > .= string concatination. Finally I regex the template - looking for my tags
> > and replave those with output. Needless to say that one page can onsists of
> > many templates (page or inside of table (bits from <tr> </tr>) etc ...).
> >
> > From Stas previous benchmarks I've preloaded the mysql driver and now
> > usually use the "push" onto array to prepare content - Thanks Stas.
> >
> > Who does everyone else do it ? Can this type of operation (that everyone
> > must do at some time) be optimised as aggressively as some of the others ?
> > Yet still keep the abstraction between design and content.
>
> As far as I've seen, the fastest template systems are the ones that
> convert the template to Perl code. So that's what I do. The templates all
> call a method (in my case $Response->Write()) which appends to a
> string. If there are no exceptions (see the guide) the string is sent to
> the browser. If there are exceptions, I parse/send an error template with
> the error in the template.
I'm curious Matt, as opposed to what?, reparsing the template each
run? Clearly reparsing would be a big loser in terms of performance.
But what other technique could be used..., hrm.., without direct
control over the pipe, I really don't think it would get too much
better than this. I mean, you could yank out sections and stuff it
into an array that would be like: text, coderef, coderef, text, etc.
Like in an ASP template you would parse the file, grab sections
between <% %> and eval it as a code ref, and stuff it into your array.
But this would probably not work specifically in ASP's case, but you
might be able to pull it off in Embperl. (Unless the array itself
could also point to arrays, etc.) Overall..., I think compiling it
directly makes a lot more sense in 99.999% of template languages...,
otherwise you'd end up putting too many restrictions on the template
language itself.
Hmm..., sort of an interesting question, what ways could be utilized
in order to maximize speed in template execution. I thought about
this a while ago, but after the fact I have to agree with Matt...,
just evaling each template as a package, or a code ref would be a
lot quicker, and if you could cook up another scheme, the resulting
code complexity might not pan out to be worth it.
> Of course I don't know if its the fastest possible method - I prefer to
> code cleanly first and worry about performance later. Much later. Clean
> code tends to lend itself to better performance in the long run anyway,
> because it's easier to optimise serious performance problems away.
Can't really disagree with that. Clean code is 100x easier to work on
later.
Shane.
Re: Template techniques
Posted by "Randal L. Schwartz" <me...@stonehenge.com>.
>>>>> "Bernhard" == Bernhard Graf <gr...@speedlink.de> writes:
Bernhard> Chris Winters wrote:
>> The newest version of Template Toolkit (currently in alpha) supports
>> compiling templates to perl code. See about 2/3 of the way down the
>> the README at www.template-toolkit.org. Why reinvent the wheel? :)
Bernhard> Also the current stable (1.06) can do this.
And Mason was doing this from the beginning. :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<me...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
[OT now] Re: Template techniques
Posted by Drew Taylor <dt...@vialogix.com>.
Andy Wardley wrote:
>
> On Jun 8, 1:56pm, Perrin Harkins wrote:
> > Not quite. The current version uses its own system of opcodes (!) which
> > are implemented as closures. Compiling to perl code gives much better
> > performance, which is why Andy is changing this.
>
> Yep, Perrin's right. Version 1 compiled templates to tree form. Items
> in the tree were scalars (plain text) or references to directive objects
> which performed some processing (like INCLUDE another template, and so
> on).
>
> This is actually pretty efficient when you have a limited directive set,
> but doesn't scale very well. For version 1.00 I was more concerned
> about getting it functioning correctly than running fast (it was already
> an order of magnitude or two faster than Text::MetaText, the predecessor,
> so I was happy). Also it was much easier to develop and evolve the toolkit
> with the tree-form architecture than when compiling to Perl, so it had some
> hidden benefit.
I was wondering if anyone had done comparisions between some of the
major templating engines. I'm thinking specifically of Template Toolkit,
Mason, HTML::Template, and EmbPerl. I currently use HTML::Template, and
am happy with it. But I am always open to suggestions.
I really like the fact that templates can be compiled to perl code &
cached. Any others besides Mason & EmbPerl (and TT in the near future)?
--
Drew Taylor
Vialogix Communications, Inc.
501 N. College Street
Charlotte, NC 28202
704 370 0550
http://www.vialogix.com/
Re: Template techniques
Posted by Andy Wardley <ab...@cre.canon.co.uk>.
On Jun 8, 1:56pm, Perrin Harkins wrote:
> Not quite. The current version uses its own system of opcodes (!) which
> are implemented as closures. Compiling to perl code gives much better
> performance, which is why Andy is changing this.
Yep, Perrin's right. Version 1 compiled templates to tree form. Items
in the tree were scalars (plain text) or references to directive objects
which performed some processing (like INCLUDE another template, and so
on).
This is actually pretty efficient when you have a limited directive set,
but doesn't scale very well. For version 1.00 I was more concerned
about getting it functioning correctly than running fast (it was already
an order of magnitude or two faster than Text::MetaText, the predecessor,
so I was happy). Also it was much easier to develop and evolve the toolkit
with the tree-form architecture than when compiling to Perl, so it had some
hidden benefit.
But the current alpha version of 2.00 compiles templates to Perl code. A
template like this:
[% INCLUDE header
title = "This is a test"
%]
Blah Blah Blah [% foo %]
[% INCLUDE footer %]
is compiled to something resembling
sub {
my $context = shift;
my $stash = $context->stash();
my $output = '';
$output .= $context->include('header', { title => 'This is a test' });
$output .= "\nBlah Blah Blah ";
$output .= $stash->get('foo');
return $output;
}
Apart from the benefits of speed, this also means that you can cache
compiled templates to disk (i.e. write the Perl to a file). Thus you
can run a web server directly from template components compiled to Perl
and you don't even need to load the template parser. Ideally, it should
be possible to integrate compiled TT templates with Mason components
and/or any other template form which gets compiled to Perl.
A
--
Andy Wardley <ab...@kfs.org> Signature regenerating. Please remain seated.
<ab...@cre.canon.co.uk> For a good time: http://www.kfs.org/~abw/
Re: Template techniques
Posted by Perrin Harkins <pe...@primenet.com>.
On Thu, 8 Jun 2000, Bernhard Graf wrote:
> Chris Winters wrote:
>
> > The newest version of Template Toolkit (currently in alpha) supports
> > compiling templates to perl code. See about 2/3 of the way down the
> > the README at www.template-toolkit.org. Why reinvent the wheel? :)
>
> Also the current stable (1.06) can do this.
Not quite. The current version uses its own system of opcodes (!) which
are implemented as closures. Compiling to perl code gives much better
performance, which is why Andy is changing this.
Template Toolkit rocks, and will rock even more when it has the extra
speed.
- Perrin
Re: Template techniques
Posted by Bernhard Graf <gr...@speedlink.de>.
Chris Winters wrote:
> The newest version of Template Toolkit (currently in alpha) supports
> compiling templates to perl code. See about 2/3 of the way down the
> the README at www.template-toolkit.org. Why reinvent the wheel? :)
Also the current stable (1.06) can do this.
--
Bernhard Graf -- s p e e d l i n k . d e -- fon +49-30-28000-182
graf@speedlink.de http://www.speedlink.de fax +49-30-28000-22
y a programmer Dircksenstraße 47 D-10178 Berlin
Re: Template techniques [ newbie alert + long ]
Posted by "Randal L. Schwartz" <me...@stonehenge.com>.
>>>>> "Perrin" == Perrin Harkins <pe...@primenet.com> writes:
Perrin> I think the world's record for most compact implementation
Perrin> goes to Randal for a small post you can find in the archive here:
Perrin> http://forum.swarthmore.edu/epigone/modperl/beldkhinfol/8ciuhsney0.fsf@gadget.cscaper.com
Ahh yes, Apache::Cachet (it's a cache, eh?), mostly proof of concept,
aborted when I started using HTML::Mason in a serious way.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<me...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Template techniques [ newbie alert + long ]
Posted by Ged Haywood <ge...@jubileegroup.co.uk>.
Hi there,
On Thu, 8 Jun 2000, Perrin Harkins wrote:
> use references for passing data.
But see "Advanced Perl Programming" pages 9 (Performance Efficiency)
and 44 (Using Typeglob Aliases).
73,
Ged.
Re: Template techniques [ newbie alert + long ]
Posted by Perrin Harkins <pe...@primenet.com>.
On Thu, 8 Jun 2000, Greg Cope wrote:
> > > - the area I was trying to explore was how to read a template (all
> > > HTML with a few <!--TAGS--> in it) and the sub in the new content.
> >
> > Embperl would work fine for that, but it's overkill. Your substitution
> > approach is slower than compiling to perl subs, especially since you have
> > to load the file, but saves lots of memory and is fine for something as
> > simple as this.
>
> Can you enlighten me into the compiling to perl subs ?
It's what Matt was talking about. Your program parses the template,
generates perl code that produces the correct output, evals the code, and
stores the results in a sub reference which you can call whenever you want
that template.
The first time I ever saw this done was with ePerl, but I don't know if
that was really the first. All the embedded perl systems popular around
here (Embperl, Apache::ASP, Mason, etc.) use some variation on this
technique. I think the world's record for most compact implementation
goes to Randal for a small post you can find in the archive here:
http://forum.swarthmore.edu/epigone/modperl/beldkhinfol/8ciuhsney0.fsf@gadget.cscaper.com
> The file gets loaded once into shared memory - most (stripped) HTML
> files are only a few 10's of K.
>
> Also the file gets loaded once at startup - not during the request
> stage.
You probably won't get much faster than that then, no matter what you do.
Just make sure your regexps are fast (maybe use "study"?) and use
references for passing data.
- Perrin
Re: Template techniques [ newbie alert + long ]
Posted by Greg Cope <gj...@rubberplant.freeserve.co.uk>.
Perrin Harkins wrote:
>
> On Thu, 8 Jun 2000, Greg Cope wrote:
> > My original question was not related to templates (I'll use embperl for
> > that)
>
> Well, I'm confused now. You'll use Embperl for templates but you're not
> using Embperl for templates?
I use Embperl when I want a templating system - but not when using HTML
templates (wrong use of names on my part) - I am refering to a template
in this case as an HTML file with a few special tags.
>
> > - the area I was trying to explore was how to read a template (all
> > HTML with a few <!--TAGS--> in it) and the sub in the new content.
>
> Embperl would work fine for that, but it's overkill. Your substitution
> approach is slower than compiling to perl subs, especially since you have
> to load the file, but saves lots of memory and is fine for something as
> simple as this.
Can you enlighten me into the compiling to perl subs ?
The file gets loaded once into shared memory - most (stripped) HTML
files are only a few 10's of K.
Also the file gets loaded once at startup - not during the request
stage.
> > Has anyone any suggestions as to speeding this up - yet keeping it
> > simple - I have played with referances to avoid all the variable copying
> > etc . ?
>
> Caching templates in memory would certainly help, but you'll eat up a
> chunk of RAM.
If the html is usually reasonable in size, and the code I C&P'ed strips
the template into one long strip with spaces / tabs (designers making
things all indented etc ..) at each end of the string - and chomp.
Also the templates are modular - in that one template covers main part
of the page, and other templates cover the rest. This helps contiunity
in HTML design etc .. (i.e only make one changen in one place)
Thanks for the input.
Greg
>
> - Perrin
Re: Template techniques [ newbie alert + long ]
Posted by Perrin Harkins <pe...@primenet.com>.
On Thu, 8 Jun 2000, Greg Cope wrote:
> My original question was not related to templates (I'll use embperl for
> that)
Well, I'm confused now. You'll use Embperl for templates but you're not
using Embperl for templates?
> - the area I was trying to explore was how to read a template (all
> HTML with a few <!--TAGS--> in it) and the sub in the new content.
Embperl would work fine for that, but it's overkill. Your substitution
approach is slower than compiling to perl subs, especially since you have
to load the file, but saves lots of memory and is fine for something as
simple as this.
> Has anyone any suggestions as to speeding this up - yet keeping it
> simple - I have played with referances to avoid all the variable copying
> etc . ?
Caching templates in memory would certainly help, but you'll eat up a
chunk of RAM.
- Perrin
Re: Template techniques [ newbie alert + long ]
Posted by Greg Cope <gj...@rubberplant.freeserve.co.uk>.
Chris Winters wrote:
>
> * shane@isupportlive.com (shane@isupportlive.com) [000608 11:07]:
> > I'm curious Matt, as opposed to what?, reparsing the template each
> > run? Clearly reparsing would be a big loser in terms of performance.
> >
> > But what other technique could be used..., hrm.., without direct
> > control over the pipe, I really don't think it would get too much
> > better than this. I mean, you could yank out sections and stuff it
> > into an array that would be like: text, coderef, coderef, text, etc.
> > Like in an ASP template you would parse the file, grab sections
> > between <% %> and eval it as a code ref, and stuff it into your array.
> > But this would probably not work specifically in ASP's case, but you
> > might be able to pull it off in Embperl. (Unless the array itself
> > could also point to arrays, etc.) Overall..., I think compiling it
> > directly makes a lot more sense in 99.999% of template languages...,
> > otherwise you'd end up putting too many restrictions on the template
> > language itself.
> >
> > Hmm..., sort of an interesting question, what ways could be utilized
> > in order to maximize speed in template execution. I thought about
> > this a while ago, but after the fact I have to agree with Matt...,
> > just evaling each template as a package, or a code ref would be a
> > lot quicker, and if you could cook up another scheme, the resulting
> > code complexity might not pan out to be worth it.
>
> The newest version of Template Toolkit (currently in alpha) supports
> compiling templates to perl code. See about 2/3 of the way down the
> the README at www.template-toolkit.org. Why reinvent the wheel? :)
My original question was not related to templates (I'll use embperl for
that) - the area I was trying to explore was how to read a template (all
HTML with a few <!--TAGS--> in it) and the sub in the new content.
My pages usually have serveral templates - or one larger template with
comments arround iterative bits (tables) so that I end up with a main
template which may look something like:
<html>
<head>
<title>
<!--TITLE-->
</title>
</head>
<body <!-- BODY -->>
<table>
<!--TABLE-->
</table>
</body></html>
and a table template:
<tr><td valign='foo' color='bar'><!--CELL--></td></tr>
The Designers / HTML coders I work with can then chop and change these
templates - I have made a template loader that strips the iterative
table content out into a seperate template, so that they can code a fake
entry for design reasons - and I then strip it out (looking for some
special HTML comment tags).
In a startup.pl The code then looks somat like this forgive the probably
uncompliable perl etc ... this is for explaination purposes:
use vars (MAINTMP TABLETMP);
$MAINTMP = &load('main.tmp');
$TABLETMP = &load('table.tmp');
sub load {
my $file = shift;
my $html = '';
open (TEMPLATE, $file) || die ('Cant open : ', $file, $!);
while (<TEMPLATE>) {
chomp;
$_ =~ s/^\s+//;
$_ =~ s/\s+$//;
$html = $html . $_;
}
close (TEMPLATE) || die ('Cant close : ', $file, $!);
return $html;
}
then in a handler:
sub makeTableContents {
# assumes @_ is a nice list in order of values
# to insert into the table ..
my $template = $TABLETMP;
my $tablehtml;
foreach (@_) {
$template ~= s/<!--CELL-->/$_/;
$tableHTML .= $template;
}
return $tableHTML;
}
sub doStuff {
# assumes that it is passed in the return value from
# makeTableContents and a title
my $tableHTML = shift;
my $title = shift;
my $template = $MAINTMP;
$template =~ s/<!--TITLE-->/$title/;
$template =~ s/<!--TABLE-->/$tableHTML/;
return $template;
}
Then when I want to send it I just print the return value of doStuff
This may not be OO - but it is simplistic, and although not benchmarked,
should be fast. I have seen another OO ish implentation, that uses a
hash a bit like Mats example - this allows more flexibility as all you
need do is add the tag to the HTML, and then add the tag to the hash -
then when you do the regex it gets put in.
Has anyone any suggestions as to speeding this up - yet keeping it
simple - I have played with referances to avoid all the variable copying
etc . ?
Thinking about it Mat's example is far more scalable, and reusable.
I am enjoying this thread ;-)
Greg Cope
> Chris
>
> --
> Chris Winters
> Internet Developer INTES Networking
> cwinters@intes.net http://www.intes.net/
> Integrated hardware/software solutions to make the Internet work for you.
Re: Template techniques
Posted by Chris Winters <cw...@intes.net>.
* shane@isupportlive.com (shane@isupportlive.com) [000608 11:07]:
> I'm curious Matt, as opposed to what?, reparsing the template each
> run? Clearly reparsing would be a big loser in terms of performance.
>
> But what other technique could be used..., hrm.., without direct
> control over the pipe, I really don't think it would get too much
> better than this. I mean, you could yank out sections and stuff it
> into an array that would be like: text, coderef, coderef, text, etc.
> Like in an ASP template you would parse the file, grab sections
> between <% %> and eval it as a code ref, and stuff it into your array.
> But this would probably not work specifically in ASP's case, but you
> might be able to pull it off in Embperl. (Unless the array itself
> could also point to arrays, etc.) Overall..., I think compiling it
> directly makes a lot more sense in 99.999% of template languages...,
> otherwise you'd end up putting too many restrictions on the template
> language itself.
>
> Hmm..., sort of an interesting question, what ways could be utilized
> in order to maximize speed in template execution. I thought about
> this a while ago, but after the fact I have to agree with Matt...,
> just evaling each template as a package, or a code ref would be a
> lot quicker, and if you could cook up another scheme, the resulting
> code complexity might not pan out to be worth it.
The newest version of Template Toolkit (currently in alpha) supports
compiling templates to perl code. See about 2/3 of the way down the
the README at www.template-toolkit.org. Why reinvent the wheel? :)
Chris
--
Chris Winters
Internet Developer INTES Networking
cwinters@intes.net http://www.intes.net/
Integrated hardware/software solutions to make the Internet work for you.
Re: Template techniques
Posted by Matt Sergeant <ma...@sergeant.org>.
On Thu, 8 Jun 2000 shane@isupportlive.com wrote:
> > As far as I've seen, the fastest template systems are the ones that
> > convert the template to Perl code. So that's what I do. The templates all
> > call a method (in my case $Response->Write()) which appends to a
> > string. If there are no exceptions (see the guide) the string is sent to
> > the browser. If there are exceptions, I parse/send an error template with
> > the error in the template.
>
> I'm curious Matt, as opposed to what?, reparsing the template each
> run? Clearly reparsing would be a big loser in terms of performance.
As opposed to parsing into a tree and working from that.
--
<Matt/>
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org http://xml.sergeant.org