Twig et template de Pluf, effet marketing d'un système de templates pour PHP
The 2009-10-08 at 06:53 by Loïc d'Anterroches filed under Pluf - Framework en PHP5.
Mise à jour : Un test "rigoureux" est disponible maintenant.
Fabien Potencier vient d’annnoncer Twig un système de gabarits pour PHP. En dehors du fait que le texte d’annonce commence par quelque chose qui ressemble à du copier/coller de la documentation du framework PHP Pluf, ce qui m’honore, le projet annonce des fonctionnalités exclusives qui en fait ne le sont pas.
Cela fait plus de 2 ans que Pluf propose l’auto échappement des variables dans les gabarits et cela même avant Django. Regardez le système de gabarit de Jelix dont est issu celui de Pluf, tout est dedans (sauf peut-être l’héritage mais il est dans celui de Pluf). Vous constaterez d’ailleurs que Fabien se garde bien de mentionner ces systèmes dans son article… manifestement il connaît bien les effets marketing des omissions bien choisies comme nos amis de Microsoft, Apple, etc…
Et c’est stupide, carTwig apporte une valeur ajoutée certaine, le mode "bac à sable" qui permet l’exécution dans un contexte restreint. C’est là la réelle valeur ajoutée de ce système de gabarit car tout le reste existe déjà, alors pourquoi ne pas mettre l’accent dessus ?
Mise à jour: Twig c’est une bibliothèque de presque 100 fichiers et 160ko, le système de templates de Pluf c’est 10 fichiers dans 70ko en comptant les tags optionnels et les exemples. J’ai un nouveau slogan pour Sensio, "Nos produits sont conçus pour vendre du service associés et des clusters pour votre application web!". Les DSI doivent se frotter les mains, cela leur fait plus de chiffre à gérer. Mais bon, je préfère l’agilité et la légèreté, chacun son truc.
Mise à jour le 10 octobre: Twig est très rapide, mais après un petit coup de xdebug (les 15 premières minutes que je passe pour optimiser le code du système de Pluf) je passe de 5% plus lent à 5% plus rapide que Twig.
Mise à jour 10 minutes après: Le benchmark de Fabien n’est pas correct on va dire. Twig est 4 fois plus lent que Pluf_Template pour 1000 rendu d’une itération sur 1000 éléments ! En gros, c’est un benchmark calculé pour le cas idéal de Twig. Par contre il y a une bonne idée dans Twig que je vais inclure dans Pluf_Template. Au lieu de faire un include à chaque rendu, le code PHP est en fait une classe avec une méthode de rendu. Donc pas besoin de 1000 include. En pratique, dans une application web, cela ne change pas grand chose, car généralement on ne fait le rendu que de 2 ou 3 templates au maximum par requête. Je vais creuser cela même si Pluf_Template est déjà plus rapide et sera toujours plus rapide que Twig. Pourquoi ? Car il fait nettement moins pour aboutir à la même chose. La meilleure façon d’aller vite est de reste simple et ne rien faire d’inutile.
Mise à jour finale ? En implémentant l’idée de la class par template, Pluf_Template est 3 à 4 fois plus rapide que Twig dans tous les scénarii. Je mets en ligne le code demain soir, car là c’est du code rapide entre les petits fours d’un mariage.
Comments from readers
perrick said:
Lors du Forum PHP, il y aura une salle dédiée pour présenter des projets Open Source : c'est peut-être l'occasion de montrer Pluf devant de nouvelles personnes. Surtout que Jelix devrait y être ! Plus d'infos sur : http://www.afup.org/pages/forumphp2009/projets-php.php
Alexandre Salomé said:
Concernant le nombre de fichier/le poids total : est-ce réellement un critère de comparaison ?
Les tests unitaires doivent-ils être comptés ?
Est-ce que la taille des fichiers est un indice de performance pertinent ?
Ne doit-on pas plutôt regarder l'occupation en mémoire / le temps d'exécution ?
Jérémie Ducastel said:
Django lui-même est à peine cité... c'est un peu triste.
Marrant, j'avais aussi réalisé une implémentation PHP de cette syntaxe il y a plus de deux ans... maintenant je code de préférence directement en python/django :)
desfrenes said:
Toi tu vas encore te faire des copains ! ^^
Juste pour signaler que Fabien Potencier peut aussi faire dans l'ultra-léger / minimal / expérimental, cf Twitto et Twittee.
Signaler aussi que Symfony n'est pas le seul framework PHP à prendre de l'embonpoint, malheureusement.
Sinon je te rejoins sur un point, annoncer comme uniques des caractéristiques qui ne le sont pas c'est un peu abusé.
Loïc said:
perrick, malheureusement je suis en Allemagne et donc faire l'aller-retour pour la conf, cela ne passera pas.
Alexandre Salomé, j'ai compté que la bibliothèque, sans les tests, ni la doc, vraiment que le code.
> Est-ce que la taille des fichiers est un indice de
> performance pertinent ?
La taille, pas trop, le nombre oui. PHP n'est pas Python, à chaque requête, dans le cas sans cache de byte code, tout le travail est à refaire. Et dans ce cas, cela veut dire faire un accès disque par fichier, avec 100 fichiers, cela dégrade terriblement les performances dès que pour une raison ou une autre les fichiers ne sont plus dans la cache de l'OS.
Ensuite, avec une cache de byte code, on a toujours le même problème que PHP doit faire la vérification des interfaces et du type hinting (je ne connais pas la traduction française) à tous les coups. Les objets doivent être remontés en mémoire etc. En gros, le byte code doit être de nouveau totalement exécuté. PHP n'est pas Python !
desfrenes, je me fous un peu des "copains", je hurle quand on présente comme du code "tout comme il faut" du code qui est le portage des erreurs de Java. Cette tendance à complexifier les bibliothèques pour les rendre plus "théoriquement" correctes avec interface et type hitting, etc. c'est renier l'avantage de PHP, sa simplicité.
PHP est merveilleux de rapidité et de puissance pour du web, pourquoi essayer de le rendre plus compliqué que du code Java ? Le retour de bâton ne va pas tarder et PHP va devenir le nouveau "bloatware", déjà qu'il avait la réputation d'être un trou de sécurité... (bloat + sécurité == Microsoft pour info).
Et si Fabien Potencier peut faire du léger, qu'il le fasse dans le code qui va rentrer en production pour de nombreuses personnes. Si les utilisateurs de son code doivent faire tourner 2 à 5 fois plus de serveurs qu'avec un framework léger, j'espère qu'ils ne font pas de la communication sur le développement durable, car là c'est raté !
Gardez votre code simple, refactorisez et n'ajoutez de la complexité que si vous ne pouvez pas, mais vraiment pas, faire autrement.
Romain said:
"La taille, pas trop, le nombre oui. PHP n'est pas Python"
J'ai envie d'y mettre une précision : le nombre _de fichiers inclus_.
Le fait que le compilateur soit découplé n'amène que du bon en lisibilité et maintenabilité de la librairie. Mais si un template est compilé, il n'y a aucune raison d'inclure le compilateur...
A mon humble avis les réelles métriques interessantes sont les performances en compilation, et les performances en utilisation précompilée.
Après je n'ai pas encore eu le temps de fouiller le code, mais d'expérience, l'optimisation des performances ne se fait pas au niveau du nombre de fichiers, mais plutôt au niveau algorithmes... Que celui qui sait optimiser un fichier de 80 Ko me fasse signe, que je rigole un peu... Que celui qui sait faire des tests unitaires lisibles et maintenables sur des classes immenses m'explique...
Ceci dit c'est marrant, on en reviens à l'éternelle question de l'homme "la votre est-elle plus longue que la mienne ?"
desfrenes said:
> desfrenes, je me fous un peu des "copains"
oui oui, ça tout le monde a remarqué et tant mieux, c'était une simple plaisanterie. Je ne viens pas ici pour lire du politiquement correct.
Je trouve aussi que le discours qui consiste à dire "peu importe les performances, le matériel coûte moins cher que les développeurs" n'est pas sain, mais dans ce domaine on peut aussi taper sur le framework zend par exemple (cf les graphs monstrueux réalisés avec inclued)
Tantek said:
C'est dommage d'employer un ton si agressif sur ce blog ; je ne sais pas ce qui pousse son auteur à rentrer dans le lard à tout ce qui bouge, mais cela dessert clairement le fond du propos qui resterait intéressant si seulement il était un peu plus argumenté, notamment pourquoi pas, avec une analyse factuelle et quantifiée du code des deux briques évoquées.
Twig semble être une brique logicielle intéressante, libre et open source, son auteur a fait l'effort louable d'écrire un très long billet expliquant précisémment et posément sa démarche, invite même au débat argumenté à son sujet et mérite à ce titre un peu mieux qu'un billet écrit à la va-vite sur un coup de sang dont on s'interroge quand même encore sur l'origine profonde.
Le marketing, c'est une chose, l'expression posée et argumentée des idées en est une autre, et il reste du travail à faire en ce sens, par ici...
(ce commentaire peut être réduis à l'état de purée d'électron, mais s'il a pu éveiller une quelconque interrogation alors c'est déjà formidable)
Loïc said:
Tantek, je ne tire pas sur tout ce qui bouge, je ne tire que sur le gros gibier. Si vous aviez pris le temps de lire ce carnet avant de réagir sur un unique billet, vous auriez découvert que je ne défends qu'une seule chose, la légèreté de PHP contre certaines tendances lourdes du "sur"-développement de certaines solutions.
Et les lecteurs qui viennent ici le savent très bien, d'ailleurs, quand j'ai un test robuste sous la main, je le lance avec plaisir comme ici : http://pluf.org/doc/performance.html
(note, je laisse toujours les commentaires même si le ton condescendant de votre commentaire et l'utilisation de la troisième personne pour vous adressez à moi n'est pas adapté et ne vous fait pas honneur)
Tantek said:
Je suis désolé de vous avoir blessé. Je ne le referai plus et n'emploierai plus jamais la 3ème personne en parlant de vous. Ou avais-je donc la tête.
Bonne continuation (et bonne chance, devrais-je ajouter).
Bertrand Mansion said:
Fabien Potencier n'a effectivement pas trop de scrupules pour s'approprier le travail des autres :
http://pear.php.net/package/Event_Dispatcher
http://components.symfony-project.org/event-dispatcher/
Les exemples sont nombreux. Mais comme l'écosystème des frameworks est principalement composé de personnes sensibles aux effets marketing et avec un niveau parfois limité en programmation, moyennant quelques efforts de communication (que tu devrais d'ailleurs faire davantage, vu la qualité de tes productions ;) ), il est plus facile de faire passer le message.