On Wed, 13 Jun 2001, Perrin Harkins wrote:
> > > wow. template toolkil took a big hit, there. (no mod_perl on
> > > this list? hmm!)
> >
> > This benchmark can be very non-representive. If you don't know how to
> > optimize each and every "thing" under test, you end up with unfair
> > benchmark and come to potentially wrong conclusions. Take TT, add compiled
> > template caching on the disk and shared TT object and I bet TT won't be at
> > the bottom.
>
> I actually helped Joshua tune the TT example a little, and it using a cached
> Template object and caching the templates used in the test in memory. The
> "slowness" comes from the fact that it provides a major feature that the
> others don't, and it is being exercised in this test. The magic dot
> notation which allows templates to say foo.bar.baz, regardless of what kind
> of data structure, object, or code ref "foo", "bar", and "baz" may be takes
> a little more work. Whether it's a good idea or not is left as an exercise
> to the reader, but I will say this: if Template Toolkit is the bottleneck in
> your app's performance, you have either done some serious tuning or written
> a really simple application (like this benchmark).
I stand corrected.
I've tried to provide a general note of not taking any numbers for
granted. Your explanation is as usual the great one :)
> Nevertheless, it's good to see some numbers, if only to convince Andy to
> finish his optimized XS version of the TT stash.
Yeah, it beats our apps' performance badly, with some 8000 calls to
_dotop() in TT in some rendered-data-heavy requests, since we use deeply
nested datastructures like foo.bar.baz. I'll probably have to rework this
if Andy doesn't come up with Stash written in XS. If you plan to work with
the current TT and are going to use lots of vars in loops, consider not to
use hashes deeper than one level, and if you still want to use them,
consider reducing the nesting level wherever possible in the templates by
doing [% baz = foo.bar.baz %] before diving into a loop where foo.bar.baz
will be constantly accessed. (of course relevant for loops with many
iterations).
Surpisingly though, TT is faster than pure Perl when it comes to writing
loops rendering data from relatively deeply nested data structures:
Benchmark: timing 2000 iterations of access_perl, access_tt...
access_perl: 7 wallclock secs ( 7.01 usr + 0.00 sys = 7.01 CPU) @
285.31/s (n=2000)
access_tt: 5 wallclock secs ( 4.19 usr + 0.05 sys = 4.24 CPU) @
471.70/s (n=2000)
Here is the benchmark I've used. (this code is a dream of calendar
programmers, since all months are 31-days long :-) :
use Time::HiRes qw( gettimeofday tv_interval );
use Template;
my $tt = Template->new();
my $data =
{
month_name => [1..12],
day_event => [ map {
[ map { {time=>1,info=>2} } 1..31 ]
} 1..12
],
};
use Benchmark;
timethese(2000,
{
access_perl => \&access_perl,
access_tt => \&access_tt,
});
sub access_tt{
my $output = '';
$tt->process(\*DATA, {data=>$data},\$output);
}
sub access_perl{
my $output = '';
for my $m (0..11){
$output .= "Month: $data->{month_name}[$m]\n";
for my $d (0..30){
my $event = $data->{day_event}[$m][$d];
$output .= "Time: $event->{time}\n";
$output .= "Info: $event->{info}\n";
}
}
}
__DATA__
[% FOR m = [0..11] %]
Month: [% data.month_name.$m %]
[% FOR d = [0..30] %]
[% event = data.day_event.$m.$d %]
Time: [% event.time %]
Info: [% event.info %]
[% END %]
[% END %]
Cool, huh?
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
