En deux jours en Allemagne, alors que la phase de vaccination de masse commence tout juste (il faut en effet se faire vacciner d’abord pour la grippe saisonnière et attendre 3 semaines avant de passer au vaccin Pandemrix H1N1) un petit bout de chou de 1 an et un homme de 55 ans sont morts dans les 24h suivants le vaccin. Une petite recherche dans la base de donnée allemande, mise à jour il y a plus de 1 semaine donne déjà plus de 200 cas de complications graves (notez que vous devez valider 7 pages de mises en garde avant d’accéder à la base de données).

Par ailleurs, pour votre information, si vous lisez qu’il y a X cas de grippe A en Allemagne, vous ne pouvez que compter comme certain que les cas de décès. Ils ne font pas de test sur les vivants cela coûte officiellement trop cher. On a donc l’assurance d’un cas une fois mort et autopsié. Le corps médical aujourd’hui n’arrive pas à faire la distinction entre une grippe saisonnière et une grippe A sans faire un test donc les statistiques ne peuvent pas être justes.

Le vaccin en général est un sujet tabou, la personne qui est contre est marquée du sceau du blasphème et ses propos ne sont plus écoutés (un peu comme les détracteurs de la saignée à une certaine époque). Le problème est qu’aujourd’hui, les commissions de validation des vaccins sont présidées par des personnes ayant des liens étroits (souvent de anciens employés) avec les laboratoires pharmaceutiques. La STIKO, qui est la commission allemande, est connue pour faire une opposition systématique à toute publication de résultats remettant en cause certains vaccins (même pas le principe de vaccin, juste un vaccin particulier). Le dernier cas en date est la tentative d’étouffement d’un vaccin 6 maladies pour enfants de 3 mois à 2 ans qui tuait avec une probabilité plus importante que la probabilité cumulée d’avoir une de ces maladies. Le vaccin a depuis été retiré du marché.

Maintenant, pensez au vaccin contre l’hépatite B en France, les cas répétés d’infirmières se choppant la maladie X ou Y alors qu’elles sont très vaccinées et bien d’autres choses étonnantes.

En Allemagne, la littérature assez impartiale sur le sujet est très limitée, le problème est que chaque vaccin est différent mais que pour les vaccins, bizarrement d’un seul coup soit on est contre, soit on est pour, mais on a pas le droit d’être un peu septique. Alors que ces mêmes personnes vont naturellement reconnaître que pour du médicament normal, il y a du bon et du mauvais. Un cas type est par exemple la réaction de Daniel Glazman, dans le domaine technologique il a une analyse très fine des avantages et inconvénients de chaque technologie, pour les vaccins, aucun doute. Si vous le lisez régulièrement vous saurez son point de vue sur certains médicaments.

Le problème du vaccin est que c’est un choc important sur le système immunitaire et que ce choc personne ou presque n’a encore pris le temps d’en analyser les conséquences et que pour stabiliser un vaccin des molécules très complexes (en fait souvent des complexes ioniques) aux effets secondaires difficilement mesurables. Le grand arguments des pros vaccin est la disparition en Europe de certaines maladies depuis les années 50, mais ils ignorent totalement l’amélioration des conditions sanitaires et oublient de dire que dans les années 50, il y avait toujours un bidonville à Paris. Un argument massue pour ne pas rentrer dans les détails.

Tous les vaccins ne sont pas mauvais, mais faire une expérience médicale sur l’ensemble de la population européenne sans aucune assurance de quoi que cela soit est un délit.

On me fait rarement parvenir une offre d’emploi aussi belle, Ecolutis embauche un développeur PHP. Lisez l’offre, même si cela ne vous intéresse pas. Lisez l’offre, surtout si vous voulez un jour embaucher quelqu’un. Lisez l’offre si vous voulez savoir pourquoi la société d’en face trouve de bons développeurs et pas vous. Lisez l’offre si vous voulez découvrir une entreprise qui pratique ce qu’elle prêche. Lisez l’offre si vous cherchez un boulot à 300 mètres de la plage.

Je viens de constater que lentement, je change ma manière d’aborder mes problèmes de programmation mais aussi ma manière de gérer mon entreprise. En fait, je change doucement ma manière d’aborder un problème qui se pose à moi.

Face à un problème, j’avais l’habitude de commencer par regarder la situation actuelle puis agir pour faire changer la situation du point actuel vers l’objectif. L’objectif étant la résolution du dit problème. À la lecture de deux billets, deux phrases ont fait tilt :

we produced a “press release” and a FAQ to further detail the how and why of what would become EC2.

et

My brain was wired to focus on the end-point and work backwards, removing each obstacle in my path or going around them all while keeping the goal in sight.

J’ai alors constaté que c’était maintenant mon approche principale pour aborder un problème sur internet. Je pense que le changement s’est principalement fait depuis que je travaille à augmenter les taux de conversions de mes différents sites. Comme je me concentre sur le taux de conversion, mon objectif devient naturellement enlever tout ce qui bloque ces taux. Une nouvelle déformation professionnelle qui finalement va assez bien avec celle que j’ai de tout optimiser.

• Relentless – The Difference Between Motion And Action
• Amazon EC2 Origins

Imaginez que vous vouliez tracer des informations dans l’exécution de votre application web, en gros, logger des informations, vous trouverez très facilement des class PHP vous permettant d’ajouter cela dans votre code :

// mon code qui fait quelque chose
$logger->log('Mon information');
Mon_Logger::debug($variable);
// la suite du code etc...

Dans le premier cas vous loggez via une méthode d’un objet, dans le suivant via une méthode statique, cela pourrait aussi être via un code du genre Factory::get('logger')->log('message').

Cette approche a malheureusement 2 problèmes :

1. une perte de performance du code en production quand on ne veut pas logger ;
2. le manque de contexte au niveau du log, il faut souvent alors ajouter des informations dans le message pour savoir d’où vient le message.

La perte de performance peut être partiellement levée par l’utilisation de l’injection de dépendances et charger ainsi un objet de log stupide, qui ne fera rien à son appel. Mais on garde alors un triple coût au niveau des performances :

1. coût de l’injection de dépendance pour charger le bon logger ;
2. coût de la génération du message pour ensuite ne rien en faire ;
3. coût de l’appel à une méthode statique PHP utilisateur, qui ne fait rien.

Dans Pluf, je n’ai pas proposé de méthode particulière et je laisse les gens utiliser le système de leur choix car je n’avais pas trouvé de méthode qui limite vraiment la perte de performance en production, jusqu’à hier.

PHP dispose des assertions, les assertions permettent d’évaluer un morceau de code et d’agir si le résultat est false. Je vous laisse lire la documentation, c’est rapide.

Les côtés très intéressants des assertions sont :

1. on peut les activer et les désactiver dynamiquement ;
2. si on passe une chaîne en entrée elle est évaluée comme du code dans le contexte local ;
3. on peut récupérer le nom du fichier et la ligne où l’exception a été exécutée via un callback.

Conclusion, vous pouvez mettre votre code à logger dans votre chaîne pour votre exception et si votre logger retourne false votre callback va se faire appeler. Si dans votre logger vous ne faites que stocker temporairement votre message, vous pouvez dans le callback reconstituer l’ensemble des informations et vraiment stocker dans votre fichier de log ou ailleurs.

Voici un bout de code pour illustrer :

<?php
function log_assert($file, $line, $code)
{
    $GLOBALS['log'][] = array(
        microtime(true),
        $file, $line, $code,
        isset($GLOBALS['last_assert_res']) ? $GLOBALS['last_assert_res'] : ''
                              );
    $GLOBALS['last_assert_res'] = null;
}

function logger($text)
{
    $GLOBALS['last_assert_res'] = $text;
    // false va forcer l'appel à log_assert
    return false; 
}

// Active les assert en les rendant silencieuses
assert_options(ASSERT_ACTIVE, 1); 
assert_options(ASSERT_WARNING, 0);
assert_options(ASSERT_QUIET_EVAL, 1);
assert_options(ASSERT_CALLBACK, 'log_assert');

$assert = array(1, 0);
$n = 10000;
foreach ($assert as $active) {
    $GLOBALS['log'] = array();
    assert_options(ASSERT_ACTIVE, $active); 
    $start = microtime(true);
    for ($i=0;$i<$n;$i++) {
        assert('logger($i.' is an integer')');
    }
    $time = microtime(true) - $start;
    print "Assert active: $active\n";
    print "Elapsed time: $time\n";
    print "Per call: ".($time/$n)."\n";
    print "Log size: ".count($GLOBALS['log'])."\n\n";
    if (count($GLOBALS['log'])) {
        var_dump($GLOBALS['log'][0]);
        print "\n\n";
    }
}

Cela vous donnera un résultat du genre :

$ php test.php 
Assert active: 1
Elapsed time: 0.403494119644
Per call: 4.03494119644E-5
Log size: 10000

array(5) {
  [0]=>
  float(1256912192.17)
  [1]=>
  string(36) "/home/loa/Projects/pluf/tmp/test.php"
  [2]=>
  int(32)
  [3]=>
  string(27) "logger($i.' is an integer')"
  [4]=>
  string(15) "0 is an integer"
}


Assert active: 0
Elapsed time: 0.03799700737
Per call: 3.799700737E-6
Log size: 0

En gros, votre logger est 10x plus rapide en production si il ne logge rien. Le assert('code') coûte autant que le coût d’un appel de la plus simple des fonctions PHP comme is_numeric ou autre, totalement négligeable en mode production. Si on compare avec l’appel à une méthode statique utilisateur qui ne fait rien, le code qui logge ne coûte que 30% de plus ! La fonction assert est donc très optimisée et on peut en profiter.

Et comme vous avez un framework bien fait, vous pouvez toujours faire la chose suivante :

1. en fonction de la requête (cookie, url, etc) activer ou non le log ;
2. accumuler les logs pendant la requête ;
3. stocker le log dans memcache ou APC en fin de requête ;
4. flusher les informations sur le disque ou dans votre base de données toutes les x requêtes/minutes.

Notez que c’est la seule manière d’avoir le contexte du message au meilleur coût (pas d’introspection). Un inconvénient quand même, votre message est l’évaluation d’une chaîne de caractères, donc cela se lit moins bien dans le code. J’ai quand même trouvé une méthode pour logger dans Pluf, chouette.

Le rappel de l’existence de assert m’a été fait par François dans les commentaires ici, merci !

Mise à jour: Ceci est une utilisation détournée de la fonction assert, cela peut poser des problèmes si vous combinez cette approche avec du code utilisant assert pour réellement faire des tests. Ce qui me rassure c’est que dans l’intégralité du code PHP que j’utilise, incluant de nombreuses bibliothèques issues de PEAR, je n’ai pas trouvé une seule utilisation de assert.

Si vous faites du type hinting, c’est qu’à priori vous faites très attention à la structure de vos projets PHP. Si vous avez un code du type :

function maFonction(MaClass $objet) {
    // corps de la fonction
    $objet->faitTruc();
    echo $objet->bidule;
}

vous n’acceptez que des objets de type MaClass en entrée. Supposons que maintenant, une personne veuille utiliser votre fonction avec un objet de la class AutreClass en sachant très bien que son objet fourni les méthodes et propriétés nécessaires à maFonction. Il ne peut pas car AutreClass n’est pas MaClass.

Une approche élégante si vous voulez donner de la flexibilité à vos utilisateurs finaux est de dire : "J’accepte tous les objets qui implémentent la bonne interface.".

 function maFonction(IMaClass $objet) {
    // corps de la fonction
    $objet->faitTruc();
    echo $objet->bidule;
}

Maintenant, il suffit que AutreClass implémente l’interface IMaClass pour satisfaire maFonction. Cela donne de la flexibilité tout en forçant un peu de contrôle car PHP au niveau du langage va forcer le respect de ce contrat entre maFonction et le paramètre. Si vous avez une utilisation parcimonieuse des interfaces dans vos logiques métier (histoire d’éviter d’avoir ensuite des class qui implémentent 5 interfaces ou plus), cela vous donne une certaine assurance, surtout si votre code est ensuite utilisé par d’autres entités dans votre société. Vous êtes certain que la personne a été obligée d’implémenter l’interface avant d’utiliser votre fonction.

Une autre approche est de demander de manière implicite l’interface sans jamais le déclarer réellement dans le code. C’est à dire que la fonction va accepter n’importe quoi :

function maFonction($objet) {
    // corps de la fonction
    $objet->faitTruc();
    echo $objet->bidule;
}

C’est alors au moment de l’exécution dans la fonction que PHP va retourner une erreur si l’interface implicite n’est pas respectée. Ceci peut être très mauvais dans certains cas. Si on suppose que maFonction fait une série d’opérations sur des fichiers et que l’objet fournit les chemins nécessaires :

function maFonction($objet) {
    grosse_copie($objet->source(), $objet->destination());
    nettoyage($objet->sourceExcludeBackup());
    echo $objet->bidule;
}

On va supposer que grosse_copie fait une grosse copie de fichiers de la source vers la destination et que nettoyage va ensuite nettoyer la source mais garder le backup. Dans ce cas là, si l’objet ne fournit pas la méthode sourceExcludeBackup, PHP va s’arrêter après la grosse copie et laisser votre système dans un mauvais état. En ayant utiliser le type hinting, PHP n’aurait même pas commencé l’exécution de maFonction, le système aurait été protégé.

Le type hinting et les interfaces ont un impact au niveau des performances et complexifie le code, donc ces outils doivent être utilisés avec soin, particulièrement dans le cœur d’exécution de votre programme mais ces outils apportent une sécurité indéniable dans certains cas particuliers, surtout dans la logique métier, là où le non respect d’une interface explicite ou implicite peut faire des dégâts.

Un endroit où je n’utiliserais pas le type hinting et les interfaces est par exemple la boucle de dispatch dans une application web. De toute façon si vos objets de requête et de réponses n’implémentent pas les bonnes méthodes, vous allez vite vous en rendre compte et les dégâts seront une requête plantée. L’erreur ne prendra pas longtemps pour être trouvée et corrigée, et dans tous les autres cas vous payerez le prix au niveau des performances, ce qui serait dommage.

Bien utilisée, la combinaison type hinting et interfaces peut donc se montrer être un outil très puissant de contrôle de la qualité.

Si vous ne connaissez pas Pluf, le framework PHP le plus rapide du monde, je vous invite à lire une petit brève ici et un benchmark de framework PHP là, vous pouvez aussi lire comment je tire à vue sur certains développements ici avec un benchmark de template PHP là.

Pluf, le framework PHP le plus rapide du monde, c’est aussi un joli troll dans les chaumières des développeurs PHP, il semble que cela commence même à troller dans les SSII sur le sujet. Aïe, pour un programmeur, voir son code être le sujet d’un troll, cela peut paraître ennuyeux, mais dans mon cas, cela me fait très plaisir. Je ne suis pas sado, loin de là, mais essayer de faire passer une idée qui va à l’encontre des pratiques du moment est toujours difficile.

Donc à toutes les personnes qui se moquent, je vous dis merci, et je vous dis surtout continuez ! Continuez de troller sur la rapidité du framework X par rapport au Y.

Maintenant pourquoi je tape sur les bibliothèques et frameworks PHP qui ne font que prendre du poids avec le temps ?

InDefero est une application web dite de forge logicielle. Vous pouvez au choix la télécharger (licence GPL) ou profiter d’un hébergement pour vous contre quelques Euros. L’hébergement InDefero c’est 1500 forges dont 1300 d’actives. Quand vous gérez cela, vous gérez un système qui au niveau performance doit supporter 50 à 100 fois plus de charge qu’une installation unique (la charge se répartie dans la journée avec les fuseaux horaires, donc ce n’est pas un facteur 1000).

Un facteur de 50 à 100, cela veut dire que très rapidement, si vous utilisez des bibliothèques qui font trop, votre composant web va s’essouffler, en gros votre serveur web ne va plus ternir la charge tout seul. Il faut être réaliste, dans la majorité des applications web, la logique métier est principalement de la requête sur la base de données. Donc on peut faire un calcul simple, de derrière d’une enveloppe et décomposer une requête web en 2 parties, logique métier et framework :

• logique métier: 50ms par requête ;
• logique framework: 50ms par requête.

On obtient donc une réponse en 100ms pour une requête, performance tout à fait honorable, on va l’appeler le cas optimisé.

Maintenant, je tape dès que je vais des facteurs 3 à 5 sur les performances des bibliothèques. Comme la logique métier est incompressible on obtient :

• logique métier: 50 ms par requête (ne change pas) ;
• logique framework: environ 150 ms par requête (facteur 3).

Total 200 ms, un facteur 2.

Cela veut dire quoi ? Cela veut dire que votre ensemble DB + serveur web va avoir besoin de 2 fois plus de cycles CPU pour servir la même charge. Cela veut dire que votre coût pour faire croître votre site va être multiplié par 2.

En fait c’est pas très juste, le premier goulot dans une architecture share nothing est toujours la base de données. Donc dès que le système ne tient plus, on déporte la base sur son serveur propre. Maintenant, on refait le calcul mais on prend en compte la distinction serveur de BD et serveur Web.

Version optimisée par requête :

• logique métier: 50ms par requête (serveur BD) ;
• logique framework: 50ms par requête (serveur Web).

Version lourde :

• logique métier: 50 ms par requête (ne change pas, serveur BD) ;
• logique framework: environ 150 ms par requête (facteur 3, serveur Web).

Maintenant, si on suppose que dans le cas optimisé un serveur web peut saturer un serveur de BD, on obtient pour assurer la même charge :

• Version optimisée : 1 serveur web et 1 serveur de base de données.
• Version lourde : 3 serveurs web et 1 serveur de base de données.

Facteur 2 au total, mais un facteur 3 sur le front end. Je vous laisse penser à tous les problèmes de répartition de la charge et de synchronisation du code que cela implique ainsi que les coûts associés. Bien entendu c’est du calcul de dos d’enveloppe donc à prendre comme un ordre de grandeur surtout l’approximation logique métier équivalente aux requêtes vers la base de données.

Pourquoi un différence si importante ? Car à tous les échelons, le choix à été fait de prendre la solution qui fait plus au cas où qui n’arrive dans 99% des cas jamais mais qui coûte 3 fois plus de cycles. L’agilité c’est introduire dans un système la complexité strictement nécessaire et suffisante en choisissant les bons outils et en refactorisant en continu. C’est très dur (j’ai vraiment du mal) mais cela vaut la peine !

Note pour les trolls : je pars en WE et ne vais avoir le temps de répondre que lundi.

Si vous ne connaissez pas Erlang prenez le temps de vous documenter un peu sur le sujet et revenez.

Une chose que j’aime beaucoup avec Erlang et la philosophie suivante :

"let some other process fix the error".

C’est une philosophie non conventionnelle dans le domaine de la programmation de systèmes complexes et pourtant elle fonctionne très très bien. Elle fonctionne très bien non pas parce que les programmeurs Erlang sont meilleurs que les autres, mais de part la nature du langage et de la VM associées et par l’utilisation abondante du principe :

Check at the interfaces and trust inside.

Grosso modo, faites votre travail de vérification en entrée mais ensuite faites confiance une fois les données dedans.

La rapidité de Pluf provient en très grande partie de l’application de ces choix, pas de type hiting, pas d’interfaces, le minimun de vérifications en interne et surtout un error_handler qui va très joliment retourner toutes les erreurs aux administrateurs avec une copie de la pile.

Pourquoi pas de type hinting et pas d’interfaces ?

Je réponds par une question : Pourquoi forcer le type et l’interface au niveau du code quand cela coûte des cycles d’exécution et que de toute façon vous faites des tests unitaires de vos programmes ? Quel bénéfice cela apporte-t’il vraiment ? Quel problème peut apporter le duck typing ?

La performance de PHP vient de sa simplicité, la résilience d’Erlang vient de la simplicité de son modèle de process… La performance vient du dépouillement pour aller à l’essentiel.

Saint Exupéry écrivait "Il semble que la perfection soit atteinte non quand il n’y a plus rien à ajouter, mais quand il n’y a plus rien à retrancher." et ce qui aurait très bien pu être la réponse d’Einstein : "Everything should be made as simple as possible, but not simpler."

Note : Je ne suis pas un programmeur de formation, mon travail qui me fait vivre est d’optimiser ça, j’ai donc une déformation professionnelle pour la simplicité et la performance et je prends donc des raccourcis dans le formalisme de la programmation. Chacun voit midi à sa porte, c’est bien connu.

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.

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 :

1. effectivement Twig est très lourd ;
2. 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…

Si vous vous demandez pourquoi je ne réponds pas à vos emails sur ma boite perso, toute la raison est dans le titre. Je suis totalement noyé. Je viens de finir de remettre mon inbox professionnelle en ordre, mais pour l’autre cela va être bien plus difficile il me semble. Je vais probablement retrouver le contrôle en septembre pendant mes vacances en France. Quand tout le monde sera couché, rien de tel que de faire du nettoyage tranquillement.

Merci de votre patience…

Pour qu’il puisse voir les limitations de mon appareil en mode macro joliment.

Si cela vous dit quelque chose et si cela vous intéresse, je raconte mon expérience dans le domaine du marketing pour un petit ISV et de mes tests AB sur blog.incontexto.com. C’est en anglais mais ce n’est pas bien compliqué.

Une seule remarque : du bonheur. Le disque SSD donne une impression de performance native. Comme je fais beaucoup de développement sous Windows en ce moment, je peux très agréablement utiliser le couple VMWare/Windows. Mes projets dans Visual Studio se chargent plus vite que Windows en natif sur disque "normal". Oui, j’ai passé ma station de travail avec un disque SSD, je n’ai donc plus qu’un unique ventilateur de 120mm à basse vitesse en fonctionnement, le silence est là…

Je suis de retour de vacances et en vacances je suis parti avec mon petit Thinkpad X61s. Dans le Thinkpad un disque Intel X25-M. Dans mon cas, c’est un disque de première génération de 80Go.

Maintenant imaginez, vous appuyez sur le bouton de votre ordinateur, vous regardez la barre d’avancement bouger, vous vous retournez pour regarder par la fenêtre quelques secondes, vous revenez vers l’écran, sans le moindre bruit ou presque, vous êtes déjà à l’écran de login. Vous entrez votre login et mot de passe et presque sans attendre votre bureau est prêt, devant vous. Comme à votre habitude, vous cliquez sur l’icône de Firefox, un firefox gavé d’extensions pour votre travail de designer et le voilà qui s’ouvre devant vous plus rapidement qu’au premier jour. Vous lancez votre client mail et vous voyez un gros document Word en attachement, vous cliquez et OpenOffice surgit sans attendre. Vous clignez des yeux, vous vous demandez si vous c’est un rêve, et puis non, c’est bien votre ordinateur.

Je suis maintenant de retour devant ma station de travail, un ordinateur plus puissant mais ayant un disque conventionnel. Arg… ce soir je passe commande d’un nouveau Intel X25-M, en plus la nouvelle génération a 2x fois plus de stockage pour le même prix que l’ancienne. Si comme moi vous n’êtes pas un ogre en termes de besoin de stockage car vous ne faites pas trop de vidéo ou photo, cela vaut vraiment la peine. Et si vous avez besoin de vraiment beaucoup d’espace disque pour certains de vos fichiers, vous pouvez toujours mettre 2 disques dans votre machine et avoir un disque pour du stockage "de masse".

Je pense très sincèrement que les disques SSD sont la meilleure évolution des ordinateurs de ces 5 dernières années. D’un seul coup, vous avez un rééquilibrage des performances ou niveau de la bande passante et de l’accès aléatoire entre tous les composants de votre systèmes. En fait, je pense en coller un dans l’ordinateur de ma femme (un vieux Pentium M 1,6GHz) et je pense qu’elle trouvera son ordinateur aussi rapide que ma station. Pourquoi ? Car aujourd’hui, 90% et peut-être plus des logiciels que nous utilisons sont limités non par la vitesse du CPU mais par le disque dur.

Un conseil achetez un disque Intel X25-M et vous ne reviendrez jamais en arrière.

Note : J’ai vraiment l’impression de faire de la pub comme quelqu’un qui s’est fait acheter, mais non, j’ai payé ce disque de ma poche. Si c’est encore trop cher pour vous (je l’utilise pour des raisons professionnelles donc je peux facilement justifier l’investissement) attendez 6 mois et cela coûtera moitié moins.

Je profite vraiment de mes vacances, je prends du temps avec la famille et les amis, il fait enfin assez beau pour aller dîner dans l’herbe au bord de la Spree (Comme Olivier, j’aime Berlin) et je ne travail pas. Du moins, je ne touche mon ordinateur que pour faire ce que je ne fais pas d’habitude.

En ce moment, je prends beaucoup de temps pour penser au marketing de mon entreprise. J’ai aujourd’hui un portfolio de services et produits de qualité, mais je reste médiocre en ce qui concerne la commercialisation de mes produits. La faute probablement à mes services qui me permettent de vivre, je n’ai donc pas de pression pour vendre.

J’ai quand même la chance d’avoir une femme extraordinaire avec les pieds sur terre, bien ancrés dans la gestion d’une boite de 200 personnes. Conclusion, le réalisme allemand m’a rappelé gentiment que j’avais tout intérêt à rentabiliser à fond mon investissement en faisant du marketing, car l’amélioration du backend de mon application, mes clients ne la voit pas. (Elle semble être assez hermétique au concept de beauté du code, du moment que c’est beau dehors, ouch).

J’ai donc décidé d’utiliser InDefero comme une plate-forme de test marketing. Le but est de tripler le taux de conversion d’InDefero. Sur les 30 derniers jours, je suis à 6,21%. Cela veut dire que 94% de mes visiteurs ne font pas la création d’une forge sur indefero.net. J’ai un très bon taux de conversion sur les téléchargements avec 20 par jours en moyenne pour 50 visiteurs uniques sur projects.ceondo.com.

Comment améliorer mon taux de conversion ? C’est sur quoi je travaille en ce moment, cela implique refaire des stats et développer un framework de split testing. Chouette des graphs, chouette de quoi s’amuser. La bonne chose avec ce système de tests est que je vais pouvoir améliorer mes logiciels en l’utilisant pour tester des idées et laisser les chiffres parler.

Je pars en famille à Berlin pendant une petite semaine, je compte bien rendre visite à un photographe du quotidien. Je serai de retour jeudi mais je garderai bien entendu mes doigts sur le clavier régulièrement.

Une nouvelle version d’InDefero est disponible. Ce petit script PHP commence à devenir vraiment complet avec revue de code, aire de téléchargement, support des dépôts Subversion, Git et Mercurial. Hier un commentaire d’un nouveau contributeur m’a fait vraiment plaisir :

I must say Pluf seems pretty easy to work with - since I have no prior PHP experience.

La personne a fait l’implémentation du support de multiples clefs SSH sans avoir de connaissance en PHP ! Cela montre que la philosophie du framework PHP Pluf est la bonne : simplicité.

Téléchargez InDefero 0.8.5 ici. Vous pouvez aussi profiter de la version hébergée.

Depuis maintenant 1,5 mois, le blog de Céondo Ltd est actif. Je l’utilise pour discuter de tout ce qu’il y a en rapport avec le développement de mon entreprise. Il tourne sous Pluf avec l’administration automatique. En fait, tout le site fonctionne avec l’autoadmin.

Bonne lecture.

Un très bon article qui illustre bien pourquoi je hurle quand je vois des frameworks introduire toujours plus de flexibilité pour des raisons très souvent d’idéal d’implémentation technique au détriment des performances et de la facilité de compréhension du code : Premature Flexibilization Is The Root of Whatever Evil Is Left.

Je n’ajoute de la flexibilité dans Pluf que si j’ai réellement besoin et si je fais cela, je m’assure de suivre la règle du projet WebKit : "The way to make a program faster is to never let it get slower".

Encore une note de service pour dire que je suis débordé avec beaucoup de travail de consultant (je vais pouvoir ajouté du rapé sur mes pâtes, yeah!) et de développement des logiciels pour Céondo, donc j’ai 76 emails non lus dans mon inbox et encore plus non répondus. Je suis désolé pour le retard, correction prévue à partir de jeudi.