If it works it to be equal or better, then we can replace LightNCandy with e.g. the more popular and dependency-free bobthecow/mustache.php package as the default fallback, and use native php-memcached when available. Which we'd recommend for large-scale installs as performance optimisation.

Some numbers:

In a July 2021 benchmark at https://github.com/zordius/HandlebarsTest, the pure PHP implementation (bobthecow/mustache.php) is about 1.9x slower than lightncandy. That is, for a template that might take 0.125ms to render for lightncandy one can expect about 0.237ms for mustache.php. That seems pretty close and within the same ballpark that I'm not worried about it as a stock default for MediaWiki core, and even for production it seems viable considering we generally only have a small number of invocations on a given web response and the numbers are low enough that it might not be somethign we even need to worry about.

Having said that, I wasn't considering composer mustache.php for production. This task is to evaluate php-mustache which is the C implementation. I'm only looking at the composer package implementation to keep a fallback for simple installs without PHP extensions installed.

The same benchmark has data from previous years going back to 2013, and in the past the difference was much bigger which suggests that mustache.php has gotten faster and/or that PHP itself has made improvements that has closed the gap between the two.

Next step for me: Add the php-mustache C lib to this benchmark, run it locally, and share with upstream (https://github.com/zordius/HandlebarsTest/issues/7).

Part of T302623, moving out of goal list as its own task.

It seems that the libmustache library used by php-mustache for actual mustache rendering purposes does not yet support referencing section data in some cases, i.e. given data like

$data = [ 'foo' => 'bar' ];

then

{{#foo}}{{.}} should be bar {{/foo}}

won't render correctly. Vector 2022 heavily uses this, so I made https://github.com/jbboehr/libmustache/pull/25 to hopefully try and fix this.

(Unverified)

bobthecow wrote at https://github.com/bobthecow/mustache.php/issues/133:

[…] i'm cleaning things up and thought I'd mention: as of v3.1.0, mustache.php is 1.6x faster than lightncandy on average, and in (contrived) extreme cases as much as 4x faster 🙂

Change #1281682 had a related patch set uploaded (by Jforrester; author: Jforrester):

[mediawiki/core@master] TemplateParser: Migrate from LightnCandy to Mustache.php

https://gerrit.wikimedia.org/r/1281682

Change #1281714 had a related patch set uploaded (by Jforrester; author: Jforrester):

[mediawiki/vendor@master] [DNM] Add mustache.php at 3.1.0

https://gerrit.wikimedia.org/r/1281714

Update: includes/Html/TemplateParser.php is far too tightly bound to LightNCandy. I think I'm going to build an alternative class using mustache.php and migrate users instead.

Change #1330614 had a related patch set uploaded (by Jforrester; author: Jforrester):

[mediawiki/core@master] [DNM] Html: Add MustacheParser, a Mustache renderer built on mustache.php

https://gerrit.wikimedia.org/r/1330614

Change #1281682 abandoned by Jforrester:

[mediawiki/core@master] TemplateParser: Migrate from LightnCandy to Mustache.php

https://gerrit.wikimedia.org/r/1281682