By default, the benchmark tests creating a new Template object every time, which no one should ever do.

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.

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.