FYI, nearly all of the popular ones compile templates to perl code. A sample run of the benchmark included with H::T::C on one of the machines at my office is here. Of these, both TT and H::T::C compile to perl code, with the difference in speed being about what I would expect from the difference in features. H::T compiles to an internal parse tree format, and H::T::JIT compiles to C code and then to a dynamic library.
By default, the benchmark tests creating a new
Template object every time, which no one should ever do.
is the TT object guaranteed to stay in shared memory? if not, it might use a lot of memory for every single apache process. (i have a little memory benchmark in the HTC package, but it needs a clean-up, so at the moment I probably don't get correct results on how much memory a TT object consumes.)
HTC is designed to stay in shared memory (*), and it does the object caching itself, so the programmer doesn't need to take care of caching the template objects. this would be nice
for TT, too.
update: ok, now I get your point - the TT object is not file specific. i'll update my testsuite, thanks =)
* except when using options formatter, filter or dumper - options which cannot be converted into written perl code at the moment
TT doesn't do anything with shared memory. It keeps the compiled templates in the local process, and shares their perl format on disk. I thought HTC did the same thing. Accessing shared memory from perl is usually pretty slow because of the need to serialize everything, so this type of setup ends up being faster for most cases. It wouldn't surprise me if TT used more memory than HTC, but I expect they aren't that far apart. A memory benchmark would certainly be interesting, but it's very hard to get accurate numbers that account for things like copy-on-write sharing.
Anyway, recreating the TT object on every request is a common mistake by new TT users. It has even more of an effect when people use many includes.