Hi Hakim,

I think you might be over analysing the problem. :-)

When a TMPL_LOOP is encountered, H::T needs to create (for want of a better description) a child context, that contains only the template variables for the child.  Each child context is effectively a new H::T object, so that the very top H::T object accumulates the output from each child.

By removing the LOOP, you are effectively completely avoiding the child context thus saving quite a significant amount of processing.

If you are looking for performance increases, you should start simply by printing a hi-res time from various points within "output()".  I have done this previously and found that I was able to find a dramatic increase in performance, just by removing foreach() loops. **

Mathew Robertson

** If you interested, I can send you a patch which ("works for me") speed's up the template-variable symbol resolution.  This patch has achieved close to 20x speed up under some circumstances. Most templates are speed up by about 1.5x.

Hakim Cassimally wrote:
Hakim Cassimally wrote:

We're having an "interesting" problem with a significant slowdown in
processing of some HTML::Template templates.

The current suspicion, after HTML bod and $boss worked on this,
by a process of elimination is that the problem is when the same
data structure is used twice in the same ->output() call.

So, in some cases, the loop "REGION" below, was used twice in
two separate TMPL_LOOP cases.  This seems to add as much as
0.5 seconds every time the parameter is reused.

The workaround seems to be to clone the data structure and
create two separate parameters, which seems very wrong.  Has
anyone else experienced this?  (It might be a feature of our
framework code rather than H::T, I'll work on the minimal test
case on Friday after a release...)


We are using:
  - using H::T 2.8 and 2.9
  - an house framework that feeds params from a CGI object to H::T
  - CGI 2.81 and 3.15
  - Perl 5.8.0 and 5.8.4

If the following conditions hold:

  - template X is <TMPL_INCL>uded
  - the parameter "region" is set (for <TMPL_LOOP NAME="REGION">)

then processing time for the template is approx 1 second longer.


  - if either the TMPL_INCL or the TMPL_LOOPs are commented, processing
    time is reduced
  - the TMPL_INCL does *not* refer to the TMPL_LOOP, and neither does the
    one template it in turn includes.

The DProf runs include the following (with some entries for BEGIN on
inhouse modules removed) :

--------------- without including TMPL_LOOP

$ dprofpp -rI 
Total Elapsed Time = 1.346560 Seconds
          Real Time = 1.346560 Seconds
Inclusive Times
%Time ExclSec CumulS #Calls sec/call Csec/c  Name
  65.7   0.030  0.885      5   0.0060 0.1770  main::BEGIN
  43.8   0.008  0.590      1   0.0083 0.5899  Our::Application::pageOutput
  43.8   0.000  0.590      1   0.0000 0.5897 
  9.43   0.050  0.127     78   0.0006 0.0016  HTML::Template::BEGIN
  8.69   0.000  0.117    539   0.0000 0.0002  JSON::Parser::value
  8.24   0.120  0.111   9267   0.0000 0.0000  HTML::Template::param
  7.28   0.000  0.098      2   0.0000 0.0488  HTML::Template::_init

--------------- with the TMPL_LOOP

$ dprofpp -rI 
Total Elapsed Time = 2.443450 Seconds
          Real Time = 2.443450 Seconds
Inclusive Times
%Time ExclSec CumulS #Calls sec/call Csec/c  Name
  109.   1.149  2.676    387   0.0030 0.0069  HTML::Template::BEGIN
  76.8   0.000  1.877      1   0.0000 1.8765 
  76.4   0.027  1.867      1   0.0275 1.8668  Our::Application::pageOutput
  55.5   0.010  1.356      8   0.0012 0.1696  HTML::Template::LOOP::output
  34.9   0.020  0.853      5   0.0040 0.1705  main::BEGIN
  10.4   0.300  0.256  28736   0.0000 0.0000  HTML::Template::param

e.g. the odd things include

- "HTML::Template::BEGIN" is called a large number of times.  I don't
   see that many BEGIN { } or 'use' blocks in the H::T code, nor do I
understand why they would be called because of a TMPL_INCL

- HTML::Template::LOOP::output takes proportionally much longer.

I'm sorry that this isn't a minimal test case - I'm working with our
HTML editor to try to identify what it is!  But if anyone has any
suggestions on where to start trying to debug this, I'd be interested,
and grateful, to see what you suggest.


Hakim (osfameron)

This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
Html-template-users mailing list