in reply to Re: Comparing HTML::Template::Compiled's compatibility to HTML::Template
in thread Comparing HTML::Template::Compiled's compatibility to HTML::Template

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.
  • Comment on Re^2: Comparing HTML::Template::Compiled's compatibility to HTML::Template

Replies are listed 'Best First'.
Re^3: Comparing HTML::Template::Compiled's compatibility to HTML::Template
by tinita (Parson) on Dec 30, 2005 at 00:17 UTC
    quote from the mailing list:
    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

[reply]

      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.

[reply]
        TT doesn't do anything with shared memory.
        I meant the copy-on-write issue. HTC keeps the compiled objects in memory, but it doesn't write on the data structure, so that it stays shared between processes when it was preloaded before forking.
        I don't know how TT handles this; is there a preload mechanism?
        It wouldn't surprise me if TT used more memory than HTC, but I expect they aren't that far apart.
        Seems like HTC uses 75-80% of the memory of TT. Which is what you would expect, probably.
        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.
        I worked on my memory benchmark a bit: bench_mem.pl
        If I didn't make a mistake, it shows that the objects stay shared for both modules (root process doesn't change its size).
        update: I think the script is still not working correctly...
        Anyway, recreating the TT object on every request is a common mistake by new TT users.
        right. it's probably because it's different from HTML::Template, for example, where an object represents a template.
[reply]

In Section Meditations