PHP 6 : ca marche et ca va vite!

Pour les besoins du Salon Linux 2008 de Paris, j'ai été amené à compiler PHP 6 sur ma machine, par un beau samedi de Janvier. Cela fait déjà 2 ans que PHP 6 compile sur mon mac (en fait, depuis PHP Québec 2006), et ce ne fut pas un exploit de réussir cette enième compilation. Mais la suite de l'étude a mené à des constats forts intéressants.

Premier contact
La première surprise été l'invite de commande disponible. Je vous le livre ici :

macadams:~/bin/php6.0-200801221530/sapi/cli macbook$ ./php 
PHP Warning:  Directive 'register_globals' is no longer supported in PHP 6 and greater in Unknown on line 0
PHP 6.0.0-dev (cli) (built: Jan 22 2008 12:45:43) 
Copyright (c) 1997-2008 The PHP Group
Zend Engine v3.0.0-dev, Copyright (c) 1998-2008 Zend Technologies

Et oui, plus moyen d'utiliser register_globals dans php.ini sans se faire apostropher. Ne vous trompez pas, si j'utilise register_globals, c'est bien pour l'avoir à OFF, comme cela devrait être le cas pour tout le monde depuis PHP 4.3. Mais en PHP 6, la directive a disparu, et même sa présence est considérée comme néfaste!

On note aussi que le Zend Engine est passé en version 3.0. Ca ne change pas grand chose, mais ca fait riche.

Taille du binaire

Voici un tableau qui va vous donner des indications sur le comportement PHP en fonction des versions.

PHP	Ext	Poids	Mémoire
4.4.8	43	8 Mo	13 ko
5.3.0	65	24 Mo	50 ko
6.0.0	43	19 Mo	53 ko

L'espace disque utilisé pour PHP a fortement cru avec PHP 5, mais semble stabilisé avec PHP 6. La réduction de la taille est probablement due au nombre moindre d'extensions. Cela dit, 20Mo de programme, pour exécuter 'Hello World', c'est tout de même quelque chose. C'est un logiciel qui occuperait la moitié du disque dur du premier ordinateur que j'ai eu (avec un disque dur). Difficile d'imaginer à l'époque, que je finirai par travailler sur de tels monstres.

La quantité de mémoire indiquée est la consommation d'un script qui ne fait que mesurer la mémoire qu'il consomme (sic). On voit aussi que PHP 4 était TRES économe, et que PHP 5 et 6 sont beaucoup plus gourmand, quoique PHP 6 ne soit pas beaucoup plus gourmand que PHP 6 : les deux sont comparables. Cet aspect est important pour pouvoir mieux dimensionner les serveurs.

Au bout du compte, malgré l'incorporation de LibICU, de IBM, pour assurer le support Unicode interne, PHP 6 a pris un embonpoint certain, mais relativement mesuré. Rien de comparable avec le saut fait entre PHP 4 et PHP 5.

Performances
Après l'installation de PHP 6, j'ai réalisé quelques tests de performances en mode cli : un processus qui exécute un million de fois une opération. On mesure le temps d'exécution, et on compare les temps d'exécution de chaque version de PHP : PHP 4.4.8, 5.3.0-dev, 6.0.0-dev.

Voici les premiers résultats obtenus, pour des boucles très simples :

• add : incrémentations d'entier
• concat : concaténations de chaines
• append : ajout d'éléments à un tableau
• md5 : md5... (sic).

Plus la courbe est basse, mieux c'est (moins de temps passé pour une tâche). Au final, PHP 6 a toujours été plus rapide en exécution que les autres versions de PHP! En performances unitaires, les versions de PHP sont effectivement de plus en plus rapide.

J'ai alors téléchargé le script de tests de John Lim : phpbench, que vous pouvez trouver sur http://linux.wareseeker.com/download/phpbench-0.8.1.rar/318050. C'est un vieux benchmark, qui travaille aussi sur des tests unitaires : les ressources traitées ne sont jamais mises en concurrences. Le jeu de tests passait très bien PHP 6, sauf pour la fonction md5 qui a demandé un transtypage forcé pour effectuer le calcul.

Ce transtypage est lié au fait que le fichier était enregistré en Latin1, et que PHP était configuré pour fonctionner en UTF-8. En lisant le script, il ne chargeait pas une chaîne de caractère valide, et la fonction md5 bloquait alors le script. Ce petit problème, rapidement réglé, illustre tout de même les problèmes qui nous attendent pour le passage à PHP 6 : il va falloir revoir les jeux de caractères de toutes nos applications.

Le correctif n'est peut être pas le plus adapté : j'aurai pu convertir le script en UTF-8, mais je n'ai pas pris le temps. Peut être plus tard?

Pour revenir à nos tests de vitesse, le résultat a été surprenant :

• PHP 6, en mode Latin1 est le plus rapide dans 34 tests sur 56.
• PHP 6, en mode Unicode, est le plus rapide dans 21 tests sur 56.
• PHP 4 est plus rapide sur un seul test.

Je vous laisse faire le calcul pour savoir dans combien de cas PHP 5 a été le plus rapide : JAMAIS. Pas une fois.

Conclusion
Le premier tour du propriétaire de PHP 6 est édifiant. La plate-forme semble promise à de beaux gains de performances, et un niveau de fonctionnalités important (85 nouvelles fonctions), qui nous feront peut-être oublier les problèmes d'incompatibilité avec les vieilles versions (on est prévenu), et les horreurs des jeux de caractères.

Si l'aventure vous tente, vous pouvez obtenir PHP 6 sur http://snaps.php.net/. qui est livré avec des instructions de compilation. Vous aurez aussi besoin de Libicu, d'IBM, http://www-306.ibm.com/software/globalization/icu/.  La compilation va prendre beaucoup de temps, et le make test encore plus : ils sont tous en double, Latin1 et Unicode. Sur Debian, Guillaume Plessis m'annonçait 10616 tests à faire. Il n'a pas l'air d'avoir fini des les faire tourner au moment ou je finis cet article.

Même si le comportement de PHP sur des scripts unitaires est alléchant, il faut tout de même faire un test d'utilisation sur un site Web, avec un lot de clients concurrents. Cela sera pour la prochaine de ce dossier.