Smarty

[boots]

Maybe the 2.6.0 code / template is sitting on a fragile part of your disk? it makes no sense. For the sake of argument, how does a STOCK 2.6.0RC1 compare to 2.5.0 (without your code changes).

greetings.

[Sepodati]

I'll try it with display(), also (w/output buffering).

I'll switch the other templates to also display within output buffering, too, to make it all equal.

---John Holmes...

[Sepodati]

I tried it with display() and using an unmodified version of 2.6 by itself, but it is still coming out slow.

You can get all of the files here:

http://sepodati.realxl.net/tpl_bench/tpl_bench.zip (380K)

to try it yourself and maybe explain what I'm doing wrong...

---John Holmes...

[boots]

Sepodati, I installed your benchmarks and I for one am seeing results consistent with what you report. Using an accelerator helps a lot (in some tests, 2.5.0 performs better than eval (w/caching, w/opts) and occasionally even better than include! (w/caching, wo/opts)) but these synthetics, where kind to 2.5.0, are apparently unkind to 2.6.0RC1.

aside: for these samples, the compiled templates that each 2.5.0 and 2.6.0RC1 generate are identical.

If I have time I will run a profile but so far I'm liking the numbers that 2.6.0RC1 is giving me with against my actual production code. An interesting situation, though. I'll have to diff your changes and dig a bit deeper.

I should have been clearer about fetch() and display()--sorry. I noticed you altered the code in index2.php and put ob_start() and ob_end_clean() around display(). It should actually be around a fetch() since display() does that implicitly but then also goes to the bother of echoing the output, which isn't required.

Nice archive, by-the-way.

[Sepodati]

What if you try the current CVS with the benchmark? Does that fare any better?

I have a job site that I'm working on right now that uses 2.5. I'll have to install 2.6 there and see if I notice a difference in speed.

---John Holmes...

[boots]

[messju]

i tracked the reason for the high-numbers for 2.6.0-RC1 down to an issue with Smarty's path-caching. it does not get triggered if you only have one call to display()/fetch() in your code, but it gets triggered by

[php:1:97b48dc87c]$smarty = new smarty()
$smarty->fetch("foo.tpl");
$smarty = new smarty()
$smarty->fetch("foo.tpl");[/php:1:97b48dc87c]

or by

[php:1:97b48dc87c]$smarty = new smarty();
$smarty->fetch("foo.tpl");
$smarty->fetch("bar.tpl");
$smarty->fetch("foo.tpl");[/php:1:97b48dc87c]

i think 2.6.0-RC2 will contain a fix for this

[boots]

@messju: wow, you tracked that quickly

[Sepodati]

[messju]

'nah, it wasn't that hard:

- load the page to ensure everything is compiled
- remove all files in smarty2.6/core
- reload the page and look where smarty pukes

if everything was okay no files from core/ are needed to display simple templates like the ones in this benchmark.
but here core.assemble_auto_filename.php was requested because the auto-filenames didn't come from the path-cache as they should have.

but thanks anyway.

[Sepodati]

I've updated the benchmark site with the (even more) modified version of 2.6RC1 and it comes out just slightly slower than 2.5. There could be other issues like this that are causing the slight slowdown, but at least it's reasonable now (and still pretty much beating the other engines!)

---John Holmes...

[boots]

Hi again.

Before I realized you updated your site, I went and did a little cheat in the index.php file, taking into account what messju said about object creation:

in Smarty2*() functions:[php:1:4bfe23bda9]global $tpl;
if !isset($tpl) {$tpl = new Smarty2;}[/php:1:4bfe23bda9]
With this change, I'm finding virtually no difference between 2.5 and 2.6--well, 2.6 is a tiny bit faster, but slightly less is being done for it. Actually, it makes me wonder if it is prudent to be including the object creation in the timing loops.

[Sepodati]

[boots]

[messju]

i think Sepodati is already überfair to smarty (and maybe the other template-engines) to not include the classes' load- and parsing-time into account. of course instanciating the template-engine-object should be taken into account when measuring the page-load time. and especially when measuring the overhead of a template-engine against a plain php approach (what Sepodati had in mind in the first place, AFAIR)

smarty-2.6.0-rc1 is slower than 2.5.0 here because of initializing the path-cache. the benchmark shows this is big overhead (2.6.0 has to handle 2 files where 2.5.0 has to handle only one). the path-cache only speeds up things when using plugins or {include} but is significant overhead in simple situations (only variable-replacements).

a the moment this is my personal result out of Sepodati's benchmark that makes me think about the path-caching-approach. unfortunately i have no estimation how complex "the average smarty-template" is to tell if the path caching is a boon or bane overall.