Performance and caching

[banks]

HI, thanks for this great port.

I really like the concept of mustache and it has finally persuaded me that PHP based views are really not the best solution in many situations.

One of the main arguments about tempting and PHP though is rendering performance. In reality this is less of an issue that it is made out to be but on a big site could be a reason not to embrace mustache in PHP.

One thing I think Twig have done well is that they compile templates into native PHP classes on first rendering and cache them so that subsequent calls don't incur the performance hit of parsing the text.

I was wondering if you felt it would be worth considering a similar approach with mustache. I realise it is actually quite a major change to output optimized PHP templates rather than compile each time. I guess in reality, parsing templates is not going to be the bottleneck in most apps so I can understand if this is not a priority, however it is possible - perhaps even not that hard - and would mitigate probably the strongest (or at least most prevalent) argument against using mustache in real projects for many.

Just a thought. It may be something I look into in a fork/alternative module - I value the simplicity of your implementation.

[banks]

Thanking about this more compiling to PHP is actually a completely different task to rendering directly. I may look at implementing something like this but I can completely understand if this is not something you will be interested in integrating here.

[zombor]

FWIW, rendering mustache templates is about 225-240% slower than native Kohana templates. Like you said, I'm not sure this matters much, as it's still pretty darn quick, and rendering views is a small part of generating a whole page view in a web app.

I've done some benchmarking for 1000 iterations: http://img.skitch.com/20100616-8d591f5yjamfqkxfdk4mmn9df.jpg

Banks, maybe caching could be part of the KOstache module, using kohana-cache module, or Kohana::cache().

[banks]

I've done some benchmarking for 1000 iterations

That is interesting. Presumably though that was a fairly basic template. I'm sure by the time you have a lot more complexity and partials etc it will start to perform significantly slower.

I know in reality though we are just talking about microseconds here and probably not significant in the real world so feel free to close this issue - time would be better spent optimizing database access and implementing robust caching than on making mustache compile to native PHP.

Banks, maybe caching could be part of the KOstache module, using kohana-cache module, or Kohana::cache().

I'm sure application level caching like that is key to real applications. I was just interested to see if the "this is slower than native PHP" argument could be easily mitigated in the same way Twig has. As we've said - it could but probably a waste of time.

[zombor]

That's actually using the demo views from the KOstache repo:

http://github.com/zombor/KOstache/blob/master/classes/view/example.php
http://github.com/zombor/KOstache/blob/master/templates/example.mustache

So there is some DB access built into it.

I made basic non-mustache php views out of the same basic logic to do the benchmarks.

[banks]

So there is some DB access built into it.

My point was more that there are only 6 variable echos and one section block (or loop) to parse/render. In a real application you are likely to end up having way more sections/variable/partials etc and/or multiple templates per page so the REGEX parsing speed becomes much more significant. Even having a largely static template with a lot of characters in is going to make the REGEX version start to struggle to keep up.

Still not arguing for a change here for reasons discussed but just clarifying what I meant.

@bobthecow - sorry for the issue hi-jack! Hope this discussion is useful for others who wonder about similar issues.

[zombor]

I agree: http://github.com/zombor/KOstache/issues/issue/2

:)

[bobthecow]

For now, the recommendation is to use set up caching at the application level rather than the template level. We can revisit this in the future when it comes time to start making this mustache implementation bloated, but for now I'm fairly convinced that it's out of this project's scope and firmly within the responsibilities of the app or framework.

[tchalvak]

@bobthecow

I'm wondering whether it would make sense to re-open this issue at least from a documentation view.

By that I mean that the docs for this implementation of Mustache seem to lack reference to the ideal compiling/caching methods. Without them, however much I like the syntax, I am not sure how to make use of php mustache in production. I'd love to fill out docs for the install & setup procedure of this as I go, though I'm not sure what a good implementation of this might be, at this stage.

[bobthecow]

First, this issue is deprecated :)

It was a feature request for native PHP compilation and caching, which, as of v2.0, Mustache.php does by default. This makes 'em about 20x faster than the previous (uncompiled) implementation. If you specify a cache directory option to the Mustache constructor, it will write the compiled PHP to the filesystem. Using this in conjunction with APC (or your favorite opcode cache of choice) makes a cache hit very very very fast.

Second, I'm not entirely sure what you mean by "ideal compiling/caching methods".

If you're talking about compiling and caching template classes, this is documented under "Constructor options" on the front page of the wiki, namely: supply a cache directory option to the Mustache constructor. That's all you need to do. Without that option, the template is compiled to PHP, but will be parsed and recompiled every time rather than cached as a file. 'Course, I'm not going to pretend that the documentation is exhaustive, so your contributions are welcome to making them more clear or accessible.

Unless you're talking about output caching, in which case I have an entirely different answer.

[tchalvak]

Awesome, pretty much exactly what I was looking for, except it's turnkey, which is even better. Good reason for me to version bump to 2.0.

So what I'll do is do that, then go through the process of caching & config see if there's anything that I can make more clear with the docs, like perhaps add the point from you that caching is now a native php compiling process. If do I find anything, I'll just make a pull request or change the wiki.

Thanks,
--Roy