Skip Menu |

This queue is for tickets about the Template-Toolkit CPAN distribution.

Report information
The Basics
Id: 19837
Status: resolved
Priority: 0/
Queue: Template-Toolkit

People
Owner: Nobody in particular
Requestors: r.preston [...] myrealbox.com
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in:
  • 2.13
  • 2.14
  • 2.15
Fixed in: (no value)



Subject: html_entities FILTER 'eval { require.. }' block can be very slow repeated on every instance of html_entities
Perl: v5.8.8 built for MSWin32-x86-multi-thread Apache: 2.0.55 I am running Template 2.15 (and was running earlier versions) under mod_perl and in one template file, I have up to 30 instances where I use the filter html_entities i.e. [% var FILTER html_entities %]. The time taken to parse this is around 6 seconds (and with these filters removed or replaced with the 'html' filter, is just 5ms). Any call to a missing package (in this case, Apache::Util) on my setup takes about 0.3 secs (stupidly long time) but, particularly given that this will be used with mod_perl on many systems, you should consider setting these two eval { require Apache::Util ..... } and eval { require HTML::Entities ..... } tests to the BEGIN block and setup references to the correct subs only once so that we wouldn't have to do the lookup on every call to this sub (would speed up normal CGI scripts too as there would only be one call perl script, rather than 30). It took me a while to see where the bottleneck was in my setup and I was quite surprised to find it here! I don't know whether there should be such a long delay for the eval { require ... } but I do know that it makes sense to take all of this into a BEGIN block to save the costly lookup being run on every call to &html_entity_filter_factory from the 'html_entities' FILTER.
From: r.preston [...] myrealbox.com
Just a quick revision to say that, of course, it is the 'html_entity' FILTER I meant to discuss, not 'html_entities', which I made up. :) Also, I have tested this on another machine this morning with an identical setup and found that the lag created in parsing the template is more like 30-40ms when called over 30 instances of 'html_entity' in the template file - and when the eval blocks are taken out and just the call to HTML::Entities::encode_entities left in, the lag in parsing the template drops to just ~4ms. This is a major increase in efficiency! I'm still puzzled as to why my home setup seems to take so much time to search the INC paths for a missing module (have tried it in a timed test script on any made up module name), but that is not for discussing here! Thanks, Russell. On Mon Jun 12 06:29:15 2006, guest wrote: Show quoted text
> Perl: v5.8.8 built for MSWin32-x86-multi-thread > Apache: 2.0.55 > > I am running Template 2.15 (and was running earlier versions) under > mod_perl and in one template file, I have up to 30 instances where I use > the filter html_entities i.e. [% var FILTER html_entities %]. The time > taken to parse this is around 6 seconds (and with these filters removed > or replaced with the 'html' filter, is just 5ms). > Any call to a missing package (in this case, Apache::Util) on my setup > takes about 0.3 secs (stupidly long time) but, particularly given that > this will be used with mod_perl on many systems, you should consider > setting these two eval { require Apache::Util ..... } and eval { require > HTML::Entities ..... } tests to the BEGIN block and setup references to > the correct subs only once so that we wouldn't have to do the lookup on > every call to this sub (would speed up normal CGI scripts too as there > would only be one call perl script, rather than 30). > It took me a while to see where the bottleneck was in my setup and I was > quite surprised to find it here! I don't know whether there should be > such a long delay for the eval { require ... } but I do know that it > makes sense to take all of this into a BEGIN block to save the costly > lookup being run on every call to &html_entity_filter_factory from the > 'html_entities' FILTER.
This has been fixed in the forthcoming v2.20.