On Fri, 24 Aug 2001, Andy Wardley wrote:
> > %Time ExclSec CumulS #Calls sec/call Csec/c Name
> > 0.06 4.705 67.230 15016 0.0003 0.0045 Template::Provider::__ANON__
>
> Makes sense. Template::Provider::__ANON__ is what the compiled template
> subs are known by. Most things happen from inside one of these.
Fair enough for the cumulative times, but the 0.003s/call seems a tad
high. Is there something I can do in my template to reduce that? Are
there any optimizations to the compiled output that could help bring
that down?
> > 0.03 2.727 10.496 70016 0.0000 0.0001 Template::Stash::XS::get
>
> Yep, every variable access. In v3, compile time constants will be
> able to eliminate some-many of these calls.
This, of course, shows up only because of the ridiculous number of times I
call it.
> > 0.03 2.572 50.012 14448 0.0002 0.0035 Template::Context::include
> > 0.02 1.639 1.559 14732 0.0001 0.0001 Template::Stash::clone
>
> These two go hand in hand. include() does little more than wait around
> for the stash to clone(), call a template sub, then return. I think
> Perrin already mentioned that PROCESS is your friend over INCLUDE for
> speed. Another thought is a copy-on-write stash which only does the
I chose INCLUDE over PROCESS strictly for the reason that the names are
very confusing and I didn't want to have to explain 3 different directives
to HTML people...
> > 0.01 1.129 1.040 16297 0.0001 0.0001 Template::Iterator::get_next
>
> Iterators are very slow compared to a regular for { } loop. In v3,
> FOREACH will be iterator driven, as currently, and FOR will be a no-
> iterator (no magic) fast loop for those who want it.
By no magic, do you mean no access to the index and loop variables? If
so, that's a price I certainly wouldn't mind paying to get that speedup.
> > 0.01 0.749 0.747 1417 0.0005 0.0005 Template::Provider::load
> > 0.01 0.719 1.121 15300 0.0000 0.0001 Template::Context::template
>
> These two are related because template() calls fetch() which calls load().
> I guess this shows up because of an underlying I/O bottleneck?
I really doubt an I/O bottleneck. There are quite a few include
paths, however. Could that also be part of the reason why load() is slow?
Thanks.
++t
Tony Payne : Sr. Software Engineer : PETsMART.com : 626-817-7151