Pluf Template 3x plus rapide et 2x moins gourmand que Twig
The 2009-10-11 at 21:54 by Loïc d'Anterroches filed under Pluf - Framework en PHP5.
La sortie de Twig annoncée par Fabien Potencier m’avait fait hurler. Twig est un système de gabarits pour PHP comme il en existe des centaines. En fait, au bout d’un certain temps, tout développeur s’est essayé à la création d’un système de gabarits/templates pour bien délimiter la logique métier de la présentation.
J’ai hurlé car Twig est une très grosse bibliothèque (presque 100 fichiers) et que cela m’a fait tout de suite penser à mes tests de performances de Pluf.
Je n’avais jamais fait la moindre optimisation du système de gabarits de Pluf et ma version n’est qu’une version simplifiée et étendue de jTpl, le système du framework Jelix, une bonne occasion de faire des tests.
J’ai d’abord mis en place des tests dont voici l’archive complète. Les premiers runs ne montraient pas de différence significative entre Twig et Pluf_Template. Frustration, comment Twig, pouvait être grosso modo aussi rapide que Pluf_Template ?
Un petit tour dans les entrailles de Twig via xdebug et je découvre que :
- effectivement Twig est très lourd ;
- mais que l’auteur est futé, le test est taillé sur mesure pour favoriser Twig.
Twig compile les gabarits en une ou plusieurs classes PHP, donc un rendu n’est qu’un appel à une fonction d’une classe. Pas besoin de faire un include comme pour Pluf. Twig génère des classes lourdes en réinventant PHP, d’où le besoin de ne faire que 3 itérations affichages dans ces tests car sinon les performances se dégradent trop. Un rendu ne devient dans ce test qu’un echo et 3 appels de fonctions.
J’ai donc repris cette idée d’une classe par gabarit et fais quelques petites optimisations par endroits, voici les résultats pour le gabarit Twig suivant :
base.html :
{% autoescape on %}<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
{% block head %}
<link rel="stylesheet" href="main.css" />
{% endblock %}
</head>
<body>
{% block content %}{% endblock %}
</body>
</html>
{% endautoescape %}
content.html :
{% extends "tbase.html" %}
{% block content %}
{% for item in items %} item {% endfor %}
{% endblock %}
Vraiment très simple, en fait un peu trop simple mais cela correspond aux tests faits par Fabien, donc cela permettra de faire une comparaison.
Les tests ont été faits sur 3 et 50 éléments dans items avec respectivement 10000 et 1000 rendus. Pour chaque test, 10 runs et les 9 meilleurs ont été conservés. Tous les temps sont sans le coût de la compilation.
Performances
| Système | Test | Rendus/s | Comparaison |
| Twig | 3/10000 | 13767 | - |
| Pluf | 3/10000 | 35151 | 2.55 fois plus rapide |
| Twig | 50/1000 | 1325 | - |
| Pluf | 50/1000 | 4300 | 3.24 fois plus rapide |
Twig est nettement plus lent, rien à commenter.
Mémoire
| Système | Test | Pic mémoire avec compilation (ko) | Pic mémoire sans (ko) | Comparaison |
| Twig | 3 itérations/1 renbu | 996 | 342 | - |
| Pluf | 3 itérations/1 rendu | 490 | 263 | 1.3 à 2 fois moins gourmand |
| Twig | 50/1000 | 1330 | 691 | - |
| Pluf | 50/1000 | 495 | 265 | 2.6 fois moins gourmand |
Les chiffres parlent d’eux-même, mais surtout, ce que je trouve très étonnant, c’est l’augmentation de l’utilisation mémoire de manière aussi importante de Twig en fonction du nombre de rendus. Des objets qui perdent de la mémoire ? Ce n’est pas très propre et je n’arrive pas à m’expliquer ces différences. Le temps de compilation est accessoire, Pluf_Template ne peut que être plus rapide mais on peut très bien précompiler tous les gabarits.
Maintenant, pourquoi battre Pluf_Template sera très dur pour quiconque ?
- Compilation : Laurent Jouanneau a eu la meilleure idée qui soit, Pluf_Template utilise directement le tokenizer de PHP, c’est le code C le mieux optimisé de PHP.
- Exécution : Le code PHP résultant est du code avec le minimum de constructions et d’appels à des fonctions. Le seul gros travail est l’autoescaping. Chose qui ne peut pas être évité dans la majorité des cas.
Conclusion
Vive le logiciel libre et la simplicité. La simplicité de Pluf_Template m’a permis d’améliorer ses performances en moins de 30 minutes grâce à ce que j’avais appris via le code de Twig. Gardez vos frameworks légers pour que la mascotte de PHP ne devienne pas un objet de moqueries…
Comments from readers
desfrenes said:
Merci Twig alors ? ;-)
Loïc said:
desfrenes, c'est clair ! Je ne suis pas le type rancunier du tout et par principe je prends tout ce qui peut améliorer les perfs de Pluf. :-)
Florent V. said:
C’est sympa les petits benchmarks, mais sur des exemples aussi simples et théoriques ça ne dit pas grand chose. Sur un ensemble de templates tirés de cas réels, là ça deviendrait plus intéressant (mais plus long à mettre en place).
Loïc said:
Florent, en fait, bien heureusement, dans ce cas là on n'a pas besoin de faire beaucoup plus. En effet, un système de templates bien foutu à la base (et Twig en fait partie) est très simple :
- on compile le code ;
- on l'exécute.
Finalement, il suffit d'évaluer le coût mémoire du chargement de la bibliothèque, le coût de la compilation (un peu accessoire car on peut la faire offline) et le coût de l'exécution.
C'est l'exécution le côté intéressant (à partir du moment où la taille de la bibliothèque est "correcte" et chacun a sa vision du correct), car c'est là où les choix se ressentent. Par exemple Twig encapsule (dans la version que j'ai testé) les itérations dans son propre itérateur là où Pluf_Template utilise directement l'array dans un foreach. De même pour l'affichage d'une valeur.
Twig permet d'aller plus loin car comme il encapsule tous les affichages, cela permet de faire des contrôles supplémentaires. mais cela à un coût. Pour le moment, dans mon utilisation réelle, je n'ai jamais eu le besoin d'aller à un niveau de contrôle supplémentaire.
Quoi qu'il en soit, Twig est basé sur un très joli code d'Armin Ronacher.