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



Reply via email to