On Sun, 28 Nov 2004 15:21:39 -0500, Perrin Harkins wrote
> On Wed, 2004-11-24 at 20:17 +0000, Simon Flack wrote:
> > How does that compare to using the COMPILE_* options in Template.pm? Am I
> > right in assuming that the COMPILE_* options will store the compiled templates
> > on disk while Perrin's patch allows you to cache the templates in memory?
>
> Sort of. Here's the deal:
>
> TT already has two levels of caching built in. The first, which is
> on by default, is caching the compiled templates in memory. They
> are turned into compiled perl subs. The second, which is what the COMPILE_*
> options affect, is storing the perl code that the templates turn into
>
> (i.e. the source for those compiled subs I mentioned) on disk, so
> that after one CGI or mod_perl process does the step of turning the template
> into perl code, the others can skip it. If this whole compilation thing
> is going over anyone's head, you might want to read my article "Choosing
> a Templating System" where I explain it in more depth.
>
> So, when using a persistent environment like mod_perl, you are supposed
> to keep the template object around between requests. This is explained
> in the TT tutorial and the book. If you don't you are throwing away
> the TT cache and making it waste lots of effort compiling each time.
> This is typically the first thing we tell people when they complain
> about performance issues on the TT list. It is, unfortunately, a common
> mistake. That's what Maypole is doing without this patch.
>
> Sometimes people create a new TT object every time because they think
> that's the only way to change the INCLUDE_PATH setting. This is a
> misconception. There are several ways to do it, and in this patch I
> chose the one that I find most aesthetically pleasing, i.e. keeping a
> reference to the Template::Provider object which provides a method
> for setting the path. You can set it as often as you want, even in the
> middle of a request.
>
> The COMPILE_* options are also important, particularly for CGI users.
> They should really always be enabled. I didn't address that in my patch
> because I don't know what the Maypole policies are about locating
> temp directories, etc.
Maypole doesn't use temp directories for anything yet. I think we need to
provide a way of passing configuration options to the view object, and
possibly set some sensible defaults, perhaps:
COMPILE_EXT => '.ttc'
COMPILE_DIR => File::Spec->tmpdir (or perhaps, leave this undef)
As I understand it, TT won't die if it can't compile() the template.
It'd be nice to be able to pass other template options to the view object,
such as DEFAULT, TRIM, EVAL_PERL, etc. OTOH, you can always subclass M::V::TT
if you have special requirements.
I need to think about this some more.
> One final tip: you should pretty much always use PROCESS, not
> INCLUDE, in your templates. The two directives are identical except
> that INCLUDE wastes a ton of time copying the entire stash of data.
> This is useful if you are planning to modify the stash data inside
> the included template and don't want any other templates to see your
> modifications, but that's almost never the case, and the speed hit
> is significant.
>
> If you have more questions about TT performance, feel free to ask me
> or the TT list.
>
> - Perrin
Thanks for taking the time to explain this. The patch (or a variant of it)
will be in the next release.
--simonflk
_______________________________________________
maypole-dev mailing list
maypole-dev at lists.netthink.co.uk
http://lists.netthink.co.uk/listinfo/maypole-dev
This archive was generated by hypermail 2.1.3 : Thu Feb 24 2005 - 22:25:57 GMT