Pascal MARTIN (n+1).zéro

Ce mois-ci sur internals@php - Avril 2013

Pascal MARTIN — Mon, 06 May 2013 07:00:00 +0200

Après un mois de mars relativement calme, voici mon dépilage d’internals@ pour le mois d’avril 2013, qui poursuit la tendance avec seulement 359 mails.

Sous forme d’un graphique représentant le nombre de mails par mois sur les trois dernières années, on obtient (l’historique depuis 1998 est disponible ici) :

La sortie de PHP 5.5 continue de se rapprocher : la version bêta3 a été publiée le 11 avril, et la bêta4 a suivi le 25 avril. Cette version bêta4 devrait être la dernière version bêta, la première version RC étant prévue pour le 9 mai.

Dmitry Stogov a travaillé sur des optimisations pour l’extension de cache d’opcodes ext/opcache qui sera inclue à PHP 5.5, et s’est demandé si ces optimisations avaient leur place dans PHP 5.5, ou s’il était plus prudent de les prévoir pour la version suivante de PHP. Une réponse apportée par Zeev Suraski est qu’il devrait être possible de mettre en place des optimisations ne travaillant que sur un seul fichier ; et que certaines idées ne mènent pas forcément à des résultats intéressants, le compilateur de PHP étant relativement rapide en lui-même. Pierre Joye, de son côté, a fait remarquer que, même si des optimisations simples pouvaient être appréciables, les versions RC de PHP 5.5 approchaient.

Comme l’a souligné Larry Garfield, une durée de compilation (compilation qui n’a lieu qu’une fois “de temps en temps”, avec un cache d’opcodes activé) un peu plus importante pour les scripts PHP est acceptable, à partir du moment où les gains à l’exécution ne sont pas négligeables.

Avec l’intégration de ext/opcache à PHP, Johannes Schlüter a fait remarquer qu’il y aurait probablement beaucoup d’utilisateurs qui essayeraient de charger cette extension avec extension= et non zend_extension= dans leurs fichiers de configuration. Le message d’erreur renvoyé lors de la tentative de chargement d’une Zend Extension avec extension= étant jusqu’à présent peu clair, pour éviter d’être submergés de demandes d’utilisateurs ne comprenant pas pourquoi ext/opcache refuse de se charger, il est proposé d’améliorer ce message — vu les nombreux retours positifs, le correctif a été intégré à PHP.

A la toute fin du mois de mars, Laruence a proposé d’ajouter une constante indiquant si PHP est compilé avec support des wrappers curl (qui sont totalement distincts de l’extension ext/curl !). Ces wrappers ayant toujours été considérés comme expérimentaux, la discussion a finalement donné lieu à la rédaction d’une RFC visant à leur suppression : RFC: Removal of curl-wrappers — et même si la décision a été un peu rapide pour rentrer dans la planning de sortie de PHP 5.5-bêta4, les wrappers curl seront supprimés pour PHP 5.5.

En tout début de mois, Sara Golemon a proposé la RFC: PHP Array API simplification : l’objectif est de fournir un fichier d’en-têtes .h permettant de simplifier les manipulations de tableaux PHP pour les développeurs d’extensions PHP (ce point ne concerne que les développeurs d’extensions, et absolument pas les utilisateurs de PHP). Comme l’a souligné Mike Willbanks, avec qui je ne peux être que d’accord, ce type de simplification est le bienvenu, en particulier pour les développeurs avec un background plus userland. La discussion n’a pas duré très longtemps et n’a pour l’instant pas mené à une inclusion de ce fichier d’en-têtes à PHP (peut-être pour une prochaine version ?), mais il peut dès maintenant être inclu manuellement par les développeurs d’extensions qui voudraient en tirer profit.

Un autre point qui peut intéresser les développeurs d’extensions PHP et/ou ceux qui aiment savoir comment ça marche : Julien Pauli a annoncé avoir rédigé un article expliquant comment PHP charge ses extensions, et les différents hooks appelés : internals:extensions. En parallèle, des améliorations sont en cours de développement autour du chargement d’extensions, et pourraient être mises en place pour PHP 5.6.

Laruence a proposé, comme décrit via le Bug #64554: var_export does not export absolute namespace for classname , d’ajouter un \ en début de noms de classes pour les sorties de var_export(), serialize(), et autres fonctions du même type. Certains ont noté que ceci semblait logique par rapport aux espaces de noms ajoutés avec PHP 5.3, alors que d’autres ont fait remarquer que cela casserait la compatibilité avec PHP <= 5.2 — et comme l’a souligné Rasmus Lerdorf, il n’est (malheureusement) pas rare de sérialiser des données avec une version de PHP, les stocker en base de données ou les envoyer via le réseau à une autre machine, et vouloir les lire avec une autre version de PHP. En conclusion, la documentation va être complétée, et le comportement de ces fonctions ne sera pas modifié.

Frank Liepert a rédigé la RFC: instance counter. Les quelques retours qui ont été postés sont assez négatifs : savoir combien d’instances d’une classe donnée existent ne semble pas vraiment intéressant ni utile. Les votes ont été ouverts sur cette RFC à la toute fin du mois — considérant le peu de discussions qu’il y a eu sur internals@ à ce sujet, je doute qu’elle passe.

Julien Pauli a proposé d’ajouter une option à phpinfo(), qui permettrait de récupérer la liste des options de configuration utilisées lors de la compilation de PHP (j’ai au passage découvert php-config --configure-options). Les retours ont été assez négatifs, puisque peu de développeurs voient l’utilité d’un mécanisme de ce type, et suggèrent de plutôt utiliser les capacités de reflection de PHP.

Julien Pauli a soumis une idée où le bloc catch d’une exception pourrait rendre le contrôle à son bloc try. Amaury Bouchard a ensuite fourni plus d’explications sur le pourquoi de cette idée. La discussion n’était pas terminée à la fin du mois, même si plusieurs semblaient penser qu’utiliser des constructions try/catch de cette manière n’était pas une bonne idée. Nous aurons peut-être l’occasion de voir le mois prochain si les choses ont évolué.

Igor Wiedler a annoncé avoir commencé à rédiger la RFC: Importing namespaced functions, et a ensuite posté quelques cas où cette idée lui semble utile. La discussion n’était pas terminée à la fin du mois, et se poursuivra peut-être en mai…

Depuis le premier article que j’ai posté dans cette série de dépilages d’internals@, en novembre 2012, je crois que c’est la première fois que j’ai aussi peu de choses à dire. C’est probablement lié aux faits que PHP 5.5 arrive tout juste à la fin de sa période de bêta, qui marquait la fin d’ajout de fonctionnalités pour cette version, et que PHP 5.6 est encore loin, et pas encore entré en phase de développement actif !

internals@lists.php.net est la mailing-list des développeurs de PHP ; elle est utilisée pour discuter des prochaines évolutions du langage, ainsi que pour échanger autour de suggestions d’améliorations ou de rapports de bugs.
Elle est publique, et tout le monde peut s’y inscrire depuis la page Mailing Lists, ou consulter ses archives en HTTP depuis php.internals ou depuis le serveur de news news://news.php.net/php.internals.

Ce mois-ci sur internals@php - Mars 2013

Pascal MARTIN — Tue, 02 Apr 2013 07:00:00 +0200

Après un mois de février plutôt chargé, voici mon dépilage d’internals@ pour le mois de mars 2013, qui a été plus calme, avec seulement 497 mails.

Sous forme d’un graphique représentant le nombre de mails par mois sur les trois dernières années, on obtient (l’historique depuis 1998 est disponible ici) :

Pour résumer de façon très rapide les quelques points principaux :

PHP 5.5 est passé en phase de beta, avec la beta2 publiée le 28 mars,
Cette phase de beta signifie la fin de l’ajout de fonctionnalités à PHP 5.5.
Zend Optimizer+ sera publié avec PHP 5.5, en tant que ext/opcache.

PHP 5.5.0 alpha6 a été publiée le 7 mars ; il était prévu que la version beta1 sorte ce jour-là, mais suite aux discussions encore en cours autour de l’intégration de Zend Optimizer+, il a été décidé de sortir une dernière version alpha.

Le 19 mars, David Soria Parra a annoncé la “Feature Freeze” de PHP 5.5 : plus aucune nouvelle fonctionnalité ne peut être ajoutée à cette version de PHP : les RFC en cours de vote pourront être mergées sur la branche PHP 5.5, mais les futures devront cibler PHP 5.6. Bien sûr, les corrections de bugs sont bienvenues sur PHP 5.5.

PHP 5.5.0 beta1 a été publiée le 21 mars, suivie d’une version beta2 le 28 mars. Il est donc largement temps pour chacun d’entre nous de commencer à tester cette version, pour valider qu’elle n’introduit pas de bug ni de régression pour nos applications ou les bibliothèques et frameworks que nous manipulons tous les jours.

Après avoir lu le fichier UPGRADING de PHP 5.5, Andi Gutmans s’est interrogé sur la fin du support de Windows XP (j’évoquais ce sujet, parmi d’autres, en novembre 2012, dans En route vers PHP 5.5 : Quelques backward-compatible breaks), qui était prévue dès la sortie de PHP 5.4, et a fait remarquer que certains points présentés comme des BC-breaks ne devaient pas avoir d’impact pour les utilisateurs de PHP (s’agissant de points internes) et devraient donc être notés un peu plus loin dans le document, de façon à ne pas décourager ceux qui voudraient migrer vers PHP 5.5.

A propos de Zend Optimizer+, Zeev Suraski a annoncé que la période de votes était terminée, et que 44 votes sur 70 étaient en faveur de l’intégration d’O+ à PHP 5.5 ; il en a profité pour dire que le préfixe des directives de configuration correspondantes serait certainement opcache. ; et qu’il restait à décider si le cache d’opcodes serait ou non activé par défaut.
Je n’entre pas dans les détails, mais la discussion a été un peu houleuse, comme le montrent par exemple ces quelques mails.

En conséquence, le 15 mars, Dmitry Stogov a annoncé qu’il allait merger Zend Optimizer+ vers PHP 5.5, avec, au passage un renommage en ext/opcache — y compris pour les directives de configuration .ini.

En parallèle, plusieurs développeurs ont commencé à utiliser O+ pour le tester, et rapporter des bugs dès maintenant — y compris sous Windows. D’autre part, comme Reeze Xia l’a fait remarquer, il serait bon que O+ continue d’être distribué sous forme de paquet PECL, pour PHP 5.3 et 5.4.

ext/opcache proposant une fonctionnalité de cache d’opcode, mais pas de cache de données utilisateur (contrairement à APC qui proposait les deux), plusieurs extensions sont en cours de développement pour mettre en place un cache de données en mémoire partagée, accessible par les différents processus PHP. Pour l’instant, Laruence a parlé de YAC, et Joe Watkins est parti sur APCu. A voir dans les prochaines semaines comment ces deux extensions évolueront.

Suite à une demande de Fabien Potencier qui souhaitait pouvoir voter sur des RFC, Hannes Magnusson a demandé qui avait le droit de voter sur des RFC : il semblerait que les choses n’aient jamais été très claires à ce niveau.

Tout d’abord, techniquement, il semblerait que n’importe qui ayant le droit de créer une RFC ait aussi le droit de voter.

D’après Pierre Joye, il apparaitrait que les contributeurs à php.net aient le droit de vote (ça ne semble pas surprenant), mais que ce soit aussi le cas pour les responsables reconnus de “projets” (dont la définition n’est pas très claire). Comme l’a souligné Derick Rethans en réponse, cela ne semble pas plus clair comme règle, et il serait bon d’avoir une liste un peu plus stricte de personnes autorisées à voter.

Dans la suite de la conversation, on en est arrivé à des avis qui remettent en question le principe de voter par le biais de RFC, regrettant l’ancienne époque des votes sur la mailing-list — qui permettaient à tout et à chacun de voter, mais qui, en même temps, donnaient peut-être parfois un peu plus de poids à ceux qui participent régulièrement à internals@.

D’ailleurs, la réponse postée par Leigh allait aussi dans le sens “ceux qui participent à internals@ et fixent des bugs devraient avoir plus de poids” — notamment par opposition à ceux qui travaillent uniquement côté userland (donc, ceux qui utilisent PHP). On retombe une fois de plus sur l’opposition développeurs de PHP vs utilisateurs de PHP, fréquemment rencontrée sur internals@.

Derick Rethans a annoncé avoir renommé le fichier NEWS de chaque branche correspondant à une version de PHP, pour qu’ils portent chacun un nom spécifique ; ce afin, à ses yeux, de faciliter les opérations lors de merges entre branches.

Sans attendre, Gustavo Lopes a fait remarquer que cela ne résolvait aucun “problème”, et qu’une solution était déjà connue et documentée, alors que Stas Malyshev et Pierre Joye faisaient noter qu’il aurait pu être intéressant d’en discuter avant d’effectuer ce renommage sans en parler à personne auparavant.

Finalement, Stas Malyshev a annulé cette modification ; mais il s’agit encore d’un élément qui pousse à croire que certains font un peu ce qu’ils veulent comme ils veulent, indépendamment des processus que les autres essayent de mettre en place…

Bob Weinand a rédigé la RFC: unset(): return bool if the variable has existed, où il proposait que unset() retourne true si la deletion a réussi, et false si elle a échoué (typiquement, s’il n’y avait rien à “unsetter”)

Sans me prononcer sur la fonctionnalité proposée, je dois dire que j’apprécie les échanges de mails qu’il y a eu, et la manière dont la RFC a été enrichie au fur et à mesure de ceux-ci, avec des cas d’usage, des résultats de benchmarks, des informations quant à l’implémentation, …

Cela dit, au bout de quelques jours, il n’y a plus eu aucun mail posté autour du sujet, qui en est à plus de vingt jour sans échange… A voir au cours des prochains mois si les choses évolueront (de toute façon, une nouvelle fonctionnalité comme celle-ci ne risquait pas d’arriver dans PHP 5.5).

Peut-être un peu brutalement, Steve Clay a lancé un sujet de discussion où il semblait qu’il demandait s’il était possible de tuer call_user_func() — il a par la suite reformulé sa question, en indiquant qu’il aurait souhaité que les callables puissent systématiquement être appelées directement, et il a apporté plus de précisions dans ce mail.

En réponse, Nikita Popov a indiqué qu’il existait déjà quelques solutions, notamment pour PHP >= 5.4, alors que Anthony Ferrara faisait remarquer qu’il existait d’autres cas pour lesquels un appel direct n’est pas autorisé, même s’il est possible de tricher avec des syntaxes du type ${'_'.!$_=getCallback()}()¹ — et pour ce second point, Stas Malyshev a indiqué qu’il existait une RFC pour cela : RFC: Function call chaining.

Depuis l’ajout “sauvage” (sans passage par le processus de RFC, et qui plus est, après peu de discussions) il y a quelques mois de la classe DateTimeImmutable, l’idée qu’elle ne fait pas ce qu’elle devrait ou qu’elle ne le fait pas comme elle devrait revient assez souvent sur le devant de la scène, au point que Nikita Popov a fini par proposer que l’ajout de cette classe soit annulé tant qu’il en est encore temps, pour éviter d’ajouter une classe dysfonctionnelle à PHP 5.5. S’est alors posée la question de “comment supprimer une fonctionnalité qui n’est pas passé par une RFC alors qu’elle aurait dû”² ^^

Suite à ces quelques mails, et pour compléter les échanges, Michael Wallner a lancé un sujet de discussion où il a indiqué ne pas être satisfait du fait que DateTimeImmutable hérite de DateTime. Après plusieurs mails partant sur autant d’idées différentes, Pierre Joye a rappelé que la marche à suivre était de créer une RFC, ce à quoi plusieurs voix ont répondu que c’était effectivement la chose à faire, mais qu’il ne fallait pas publier DateTimeImmutable telle qu’elle est à présent inclue dans PHP 5.5.

Cela dit, en fin de mois, Derick Rethans semblait refuser d’annuler l’ajout de cette classe DateTimeImmutable. Nous verrons dans les prochaines semaines comment les choses évolueront, si l’architecture de cette classe sera revue, si son ajout sera finalement annulé, ou si elle sortira en l’état…

J’évoquais en février l’idée que certains avaient de réaliser un sondage, pour permettre aux développeurs de PHP de connaitre un peu mieux les besoins de leurs utilisateurs. Paul Reinheimer a continué à travailler sur le sujet, et a proposé une première série de questions.

La bibliothèque PCRE a été montée en version 8.32 sur toutes les branches de développement.

La RFC: PHP CLI changing process title support qui avait été ouverte aux votes le mois dernier est passée, avec 28 votes “pour”, et 1 vote “contre” ; la fonctionnalité a été intégrée à PHP 5.5.

La RFC: Allow non-scalar keys in foreach qui avait été ouverte aux votes en fin de mois dernier est elle aussi passée, avec 21 votes “pour”, et 0 vote “contre”. Suite à cette annonce, quelques échanges ont eu lieu, en particulier entre Nikita Popov, auteur de la RFC et du patch l’accompagnant, et Dmitry Stogov, visant à améliorer ledit patch. La fonctionnalité a été mergée vers PHP 5.5.

Là aussi dans la suite logique de ce que je disais le mois dernier, les votes ont été ouverts sur la RFC: Trailing comma function args. Pour l’instant, les choses semblent relativement mal parties, avec 15 votes “pour” et 20 votes “contre”, alors que la fonctionnalité décrite semblait initialement intéresser du monde — mais comme l’a souligné Sara Golemon, c’est aussi à ça que sert le processus de RFC.

Richard Bradley a lancé l’idée de transformer l’E_ERROR obtenue lors de l’appel d’une méthode sur une variable valant null en E_RECOVERABLE_ERROR, afin que le script PHP ayant provoqué l’erreur puisse l’intercepter et la gérer. Au vu des quelques échanges qui ont suivi, on peut espérer qu’une RFC soit rédigée dans les prochaines semaines.

Stas Malyshev a rédigé la RFC: Secured unserialize(). En réponse, Anthony Ferrara s’est demandé s’il valait mieux essayer de sécuriser le principe de sérialisation/désérialisation, ou s’il était plus judicieux de recommander l’utilisation d’un autre format de données (comme JSON ou XML), interoppérable, lors d’échange d’informations.

Et pour finir, Nikita Popov a commencé à faire une passe sur l’implémentation des Generators de PHP 5.5, et a demandé s’il ne faudrait pas supprimer le support de leur clonage. La seule réponse postée va dans le sens de cette proposition.

Je suis assez d’accord avec Sara Golemon et Julien Pauli : cette solution est dingue — mais plutôt sympa à lire ^^ ↩
Considérant les échanges de ces derniers mois autour de la classe DateTimeImmutable, et le fait qu’il l’ait commitée sauvagement sans passer par une RFC, la logique voudrait que Derick Rethans annule cet ajout… Je suis curieux de voir ce que cela va donner sur les prochains semaines, maintenant que PHP 5.5 est feature-frozen, cela dit… ↩

Ce mois-ci sur internals@php - Février 2013

Pascal MARTIN — Mon, 11 Mar 2013 07:00:00 +0100

Après un mois de janvier agité sur internals@, voici février 2013, qui n’a pas non plus été de tout repos !

Sous forme d’un graphique représentant le nombre de mails par mois sur les trois dernières années, on obtient (l’historique depuis 1998 est disponible ici) :

Pour résumer de façon très rapide les quelques points principaux :

PHP 5.5 continue d’avancer : une version alpha5 a été publiée, et la sortie de la version beta1 a été repoussée.
Le vote sur l’intégration de Zend Optimizer+ à PHP 5.5 a été ouvert en fin de mois.
Plusieurs petites RFC ont été rédigées ; pas de grosse nouveauté cela dit — ce qui peut se comprendre, puisque le focus du moment est la sortie prochaine de PHP 5.5.

PHP 5.5 : Avancement

La sortie de PHP 5.5 continue de se rapprocher doucement, mais de plus en plus sûrement, avec la sortie d’une version alpha5, et de longues discussions autour du composant Zend Optimizer+ et de sa possible intégration à PHP 5.5.

PHP 5.5 : roadmap, alpha5, future beta1 ?

Je disais il y a un mois que, suite aux échanges survenus fin janvier autour de la possible intégration d’un cache d’opcodes à PHP 5.5, il se pourrait que cette version soit repoussée — autrement dit, que la beta1 ne soit pas publiée le 7 février comme initialement prévu.

Et effectivement, tout juste à la mi-février, Julien Pauli et David Soria Parra ont effectué les annonces suivantes :

Une version alpha5 doit être publiée le 21 février, intégrant Zend Optimizer+, extension qui aura été mergée au coeur de PHP d’ici là,
La beta1 est repoussée au 7 mars — soit un mois après la date initialement prévue,.

Les réactions ne se sont pas faites attendre : plusieurs voix se sont élevées, indiquant que le vote sur la RFC: Integrating Zend Optimizer+ into the PHP distribution n’avait pas encore eu lieu, et qu’il semblait donc “prématuré” d’annoncer dès maintenant l’intégration de cette extension (intégration qui n’a pas été votée !) ; et aussi que ce planning ne laissait que peu de temps pour tester avant le passage en phase de beta.

Heureusement, David Soria Parra a rapidement apporté quelques clarifications :

Les deux release managers pensent que l’intégration d’un cache d’opcode est importante, et espèrent donc que la RFC va passer.
Ils ont donc souhaité rallonger la phase de versions alpha pour permettre le merge de Zend Optimizer+ au coeur de PHP avant le passage en phase de beta,
Mais l’intégration de Zend Optimizer+ à PHP 5.5 n’aura lieu que si la RFC est acceptée.

Le 22 février, soit une semaine après cette annonce, la version alpha5 de PHP 5.5 a été publiée.
Finalement, ZendOptimizer+ n’a pas été intégré à cette version, qui n’a apportée que quelques corrections de bugs et améliorations (autour de l’extension mysqli et de mysqlnd, notamment).

La sortie de la première version beta (qui signifie la fin de l’ajout de fonctionnalités à PHP 5.5) approchant, Pierre Joye a demandé, en toute fin de mois, à ce que les prochaines RFC, pull-requests, et suggestions d’ajout de fonctionnalités visent PHP 5.6 — et plus PHP 5.5.

PHP 5.5 et Zend Optimizer+

Comme je l’évoquais il y a quelques semaines, toute fin janvier, Zeev Suraski annonçait la RFC: Integrating Zend Optimizer+ into the PHP distribution ; l’idée étant d’open-sourcer le cache d’opcodes Zend Optimizer+ (jusqu’à présent gratuit, mais closed-source) afin de l’intégrer à PHP, même si cela pouvait signifier devoir repousser la sortie de PHP 5.5 de deux mois.

Quelques mails supplémentaires ont été échangés en février sur ce fil de discussion, sans apporter beaucoup plus d’informations, mais continuant à indiquer que le sujet intéresse du monde. Au bout de quelques jours, un tier du mois étant passé, Zeev Suraski a indiqué que le processus prenait un peu plus de temps que prévu, mais que la première version des sources devrait arriver incessamment sous peu.

Et effectivement, le lendemain, Zeev Suraski a annoncé que les sources de Zend Optimizer+ étaient disponible sur github/zend-dev/ZendOptimizerPlus/ — l’extension en elle-même étant compatible avec toutes les versions de PHP allant de 5.2 à 5.5-dev. Il en a profité pour indiquer qu’il était possible d’organiser un webinar, afin de faciliter la prise en main du code de l’extension et de son fonctionnement par d’autres développeurs (idée qui a semblé interresser du monde — ce qui ne peut être qu’une bonne chose : plus il y a de développeurs connaissant le code, mieux il sera revu et testé).

En réponse à une série de questions de Christopher Jones, Zeev Suraski a apporté quelques informations supplémentaires :

D’après lui, le cache d’opcodes devrait être activé par défaut — si O+ est intégré à PHP, bien sûr.
O+ est capable d’effectuer quelques optimisations — d’ailleurs, ces optimisations pouvant être coûteuses à réaliser, il semble cohérent de les coupler avec un cache d’opcodes.
En l’état actuel des choses (et comme pour APC, d’ailleurs), il n’y a pas de caching d’opcode en CLI, puisque le processus est détruit une fois le script exécuté : la mémoire ne persiste pas “en dehors” de PHP.

Plus loin dans la discussion se sont posées quelques questions supplémentaires :

Quel nom utiliser pour cette extension ? Y compris si elle est intégrée à PHP ? Considérant que ce nom doit être explicite, et sera aussi probablement utilisé pour une série de paramètres dans php.ini. Sur ce point, Zeev Suraski est tout à fait d’accord pour qu’un autre nom que “Zend Optimizer+” soit utilisé.
Quelles valeurs par défaut utiliser pour ces différents paramètres ? Des valeurs plutôt “prudentes”, ou plutôt orientées “performances extrêmes” ?

D’autres échanges de mails indiquent que plusieurs développeurs ont compilé et/ou essayé l’extension :

Pierre Joye l’a compilée pour Windows (quelques correctifs ont été apportés au passage — à peine open-source, et déjà des pull-requests ;-) ),
Il semblerait qu’il puisse effectivement (c’était prévu) y avoir quelques soucis avec ZTS.

Après deux semaines d’échanges, les votes ont été ouverts sur la RFC: Integrating Zend Optimizer+ into the PHP distribution à la toute fin du mois.

Quelques jours après la publication des sources de Zend Optimizer+, Pierre Joye a publié les résultats de quelques benchmarks sous Windows ; il en a d’ailleurs profité pour suggérer qu’il serait intéressant de publier l’extension sur PECL rapidement, afin d’augmenter le nombre de testeurs.

Les premiers résultats semblaient remonter quelques problèmes avec Symfony (les différences pour Mediawiki pouvant — en partie ? — être expliquées par le fait qu’O+ n’intégre pas de cache de données, contrairement à APC et à Wincache : Zend Optimizer+ ne fait que du caching d’opcodes.). Un correctif a été apporté, qui semble avoir amélioré les choses.

Ces benchmarks devraient être joués régulièrement, et les résultats sont disponibles en ligne.

Pour ceux qui voudraient tester O+ sur un environnement de développement où ils auraient aussi Xdebug, notez qu’il semble falloir charger Zend Optimizer+ avant Xdebug — les choses fonctionnant moins bien si l’extension Xdebug est chargée en premier.

Ralph Schindler a fait quelques tests avec des archives Phar, et a répondu à un mail qu’il avait lui-même envoyé y a quelques mois, en notant que O+ ne semble pas souffrir de certains problèmes qu’il avait rencontré avec APC pour les stat/include avec des Phar.

Give the Language a Rest motion

Probablement suite aux nombreuses conversations de ces derniers mois à propos de modifications qui pourraient être à apporter à la syntaxe de PHP ou de nouveautés indispensables d’après certains, Derick Rethans a renvoyé un mail que Zeev Suraski avait initialement posté en mars 2006.

Déjà à ce moment là, Zeev Suraski estimait qu’il n’était pas judicieux de vouloir sans-cesse continuer à altérer la syntaxe de PHP pour ajouter de nouvelles fonctionnalités qui semblaient perçues comme indispensables par seulement un petit nombre.

Pierre Joye a rapidement profité de l’occasion pour rappeler qu’il serait bon pour les développeurs de PHP de se rapprocher des différentes communautés utilisant le langage, afin d’être plus en mesure de comprendre leurs besoins.

La réponse de Lars Strojny est intéressante : d’après lui, il bien entendu important de ne pas ajouter de fonctionnalité seulement à moitié réfléchie, mais il faut continuer à implémenter des nouveautés, pour que ce qui est faisable avec d’autres langages le soit aussi en PHP, pour permettre aux développeurs de travailler avec une syntaxe concise, ainsi que pour apporter des nouveautés les aidant, alors qu’ils ne pensaient même pas qu’ils en auraient besoin. Son mail comportait aussi un résumé un peu macro des nouveautés, en termes de syntaxe, apportées par les quelques dernières versions de PHP.

Cela dit, le point de vue de Zeev Suraski se défend aussi : comme il le souligne, ajouter de nouvelles fonctionnalités rend le langage de plus en plus complexe, et, par conséquent, moins accessible à de nouveaux développeurs (j’ajouterais qu’il est facile d’oublier ce point lorsque l’on travaille quotidiennement avec PHP depuis des annéees et que l’on suit ses évolutions au fur et à mesure de leur sortie) ; et en même temps, chaque nouvelle fonctionnalité ajoute de la complexité dans le moteur de PHP, rendant potentiellement sa maintenance plus difficile.
Je ne peux d’ailleurs que sourire lorsque je lis le passage suivant, qui fait sans aucun doute référence à Perl¹(d’aucun diront que ça peut sonner un peu “arrogant”, mais, en même temps, c’est plutôt vrai, non ?) :

There used to be a language that was the Queen of the Web. It was full of
clever syntax. It prided itself on having a variety of expressive ways of
doing the same thing. You’re on the mailing list of the language that
dethroned it.

D’un autre côté, la notion de “retour sur investissement” est perçue différemment par chacun, et là où certaines fonctionnalités sont perçues comme inutiles par l’un, elles sont fortement attendues par d’autres — je pense par exemple aux annotations ou aux getters/setters dont j’ai parlé plusieurs fois ces derniers mois — et comme l’a souligné Pierre Joye, il est absolument nécessaire d’arriver à des compromis entre la simplicité qui était attendue dans les années 2000, et les besoins du développement “moderne”.

Rasmus Lerdorf a ensuite apporté un point de vue différent : là où le débat se focalisait jusqu’à présent sur des évolutions en termes de fonctionnalités, il ne faut pas oublier que pour certains, les nouvelles fonctionnalités et changements syntaxiques ne sont pas forcément désirés, et que des optimisations orientées performances sont beaucoup plus attendues — alors que le sujet des performances n’est que rarement abordé sur internals@, contrairement aux idées de fonctionnalités !

Et en même temps, comme l’a souligné (entre autres) Florin Razvan Patan, il serait aussi bon de se concentrer sur la fiabilité et la robustesse du langage : lorsqu’une nouvelle version apporte son lots de BC-breaks (si je puis me permettre de nuancer : il n’y en n’a pas non plus eu tant que ça avec PHP 5.4 ; et il n’y en n’a pas tant que ça de prévus pour PHP 5.5) et que des extensions critiques ne sont pas fonctionnelles avant presque un an, il ne faut pas s’étonner si elle n’est adoptée qu’extrêmement lentement — la suite de son mail est intéressante, il y évoquait différents points en rapport avec le trop faible nombre de contributeurs à PHP, et quelques idées qui pourraient aider à améliorer les choses.

Versionner le langage pour réduire les bc-breaks ?

Le mois a commencé fort, avec une discussion de plus de 45 mails lancée par Karoly Negyesi, où il suggèrait initialement que, pour faciliter la migration vers PHP 6, cette version devrait se baser sur des tags <?php incluant la version du langage, comme <?php6.

Cette idée n’est pas nouvelle, et il n’y a d’après Pierre Joye aucune chance d’y revenir ; il n’est d’ailleurs pas le seul de cet avis.

Comme Rasmus Lerdorf le souligne, il n’est pas réaliste de considérer qu’aucune cassure de compatibilité antérieure ne doit avoir lieu entre deux versions — y compris mineures — de PHP : cela signifierait que même les bugs ne doivent pas être corrigés (puisque ces corrections signifient un changement de comportement). Dans les grandes lignes, l’approche retenue pour PHP est qu’il ne doit pas y avoir de changement sur un comportement fonctionnel documenté, à moins qu’il n’y ait une raison extrêmement sérieuse (en général, liée à une problématique de sécurité) de le faire.

Un peu plus loin dans la conversation, cela dit, Karoly Negyesi a expliqué son point de vue et le pourquoi de sa proposition : on retombe sur le problème des hébergeurs (y compris mutualisés, qui représentent une part non-négligeable, au contraire, des systèmes sur lesquels sont déployés nombre de CMS) et distributions (comme la dernière Ubuntu LTS qui est encore en PHP 5.3 et ne propose toujours pas PHP 5.4) ne mettant pas PHP à jour, et continuant à proposer d’anciennes versions à leurs clients / utilisateurs.
En somme, à ses yeux, il faudrait que tout code écrit pour PHP 5.4 fonctionne sans erreur sur PHP 5.5 ; ce à quoi Rasmus Lerdorf a fort justement répondu que la première chose à faire, alors, serait de tester avec PHP 5.5 (ce serait même un bon moyen, peu coûteux en temps, de contribuer au projet PHP !), même si cette version n’est pas encore sortie en stable — et que chaque version de PHP apporte nécessairement quelques changements.

La discussion a quelque peu dévié sur les différentes versions de PHP, et sur la baisse de PHP 5.1 vs l’augmentation de PHP 5.4 vs le besoin de migrer vers PHP 5.3, ainsi que sur les méthodes de calcul, avant de revenir sur le besoin qu’expriment certains d’avoir une version “figée” de PHP 5 — et que les développements soient effectués sur une autre version réellement distincte.
Mais, en même temps, il semble normal qu’une évolution (comme un changement de version d’un composant majeur) de la plate-forme d’hébergement puisse s’accompagner de retouches au code PHP qu’elle fait tourner, non ?
Et comme l’a noté Thomas Bley, il est tout à fait possible d’utiliser plusieurs versions de PHP en parallèle sur une machine — en particulier avec FPM.

Les échanges s’éternisant quelque peu, avec d’un côté quelques participants refusant qu’une nouvelle version de PHP ne change quoi que ce soit² et de l’autre ceux qui considèrent qu’il est impossible d’éviter tout changement, plusieurs voix se sont élevées pour signifier que la marche à suivre serait de rédiger une RFC (qui n’a aucune chance de passer). Et au final, après trois jours de “discussions”, le sujet est retombé.

Divers / en vrac

Martin Keckeis a fait remarquer que la page de statistiques d’utilisation de PHP sur php.net n’était pas à jour (les derniers chiffres datent de 2007) ; Peter Cowburn a indiqué en réponse qu’il était en contact avec netcraft, et qu’il allait voir pour mettre ces statistiques plus régulièrement — presque un mois après, il n’y a pas encore eu de progrès sur ce point.

Ce n’est pas un événement en soit, mais ça m’a permis de découvrir le Jenkins d’intégration continue de PHP : Ferenc Kovacs a demandé un accès au repository git “jenkins” de PHP, pour pouvoir conserver sous gestionnaire de sources la configuration de ce dernier.

A propos de caches d’opcodes, Terry Ellison a souligné que les extensions existantes se focalisaient sur le caching dans un contexte de serveur Web servant de nombreuses requêtes, et ignoraient le cas de scripts lancés en CLI ; il en a profité pour introduire son extension LPC, qui pourrait conduire à quelque chose à ce niveau — mail qui n’a été suivi d’absolument aucun retour.

Hans-Juergen Petrich a lancé une discussion où il remarquait qu’utiliser eval() pour créer des fonctions anonymes³ entraine une fuite mémoire, si les fonctions anonymes créées le sont à partir de chaines de longueurs différentes. Après un peu de recherches à coups de debugger, Terry Ellison a noté qu’il semblait s’agir d’un bug.

Gabriel Wu a annoncé s’être mis à travailler sur l’extension operator, dont la dernière mise à jour remontait à 2006, pour, en premier lieu, la rendre compatible avec PHP 5.3 et PHP 5.4. L’échanges de mails montre un peu le processus à suivre pour devenir mainteneur d’une extension : travailler dessus, éventuellement montrer un patch ou deux (il semblerait que ça n’ait pas été le cas ici, mais il s’agit d’une extension peu utilisée, qui n’avait plus de mainteneur — ce qui facilite les choses), demander un compte pecl (pour pouvoir publier des mises à jour de l’extension) et éventuellement un compte php.net (pour héberger les sources sur le repository git correspondant, si on ne veut pas les héberger en externe), et demander aux plus expérimentés s’ils ont des conseils et retours.

Les sources de PHP sont hébergées sur un repository git, dont il existe un miroir sur github — miroir qui reçoit des pull-requests.
Là où il existait déjà l’outil Github Pull Requests pour gérer celles-ci et les merger sur le repository officiel, Johannes Schlüter a annoncé la mise en place d’un mécanisme les remontant sur le bug-tracker de PHP, en vue de faciliter le rapprochement entre un bug et une PR lui correspondant. Encore un bon point pour encourager la soumission de pull-requests, et donc la participation de nouveaux développeurs !

Il y a quelques mois, Ferenc Kovacs proposait un mail expliquant qui pouvait soumettre des RFC ; ce mois-ci, Christopher Jones a complété cette liste, en postant sur son blog : The Mysterious PHP RFC Process and How You Can Change the Web.

Asbjørn_Sannes a soumis la RFC: Add mysqlnd.localhost_override option ; après plusieurs retours plutôt négatifs, dont certains proposant d’autres solutions, la RFC est retirée.

Pour continuer avec une autre RFC, Nikita Popov a annoncé qu’il prenait la suite du travail sur la RFC: Allow non-scalar keys in foreach. Il n’y a eu que peu d’échanges sur le fil de discussion (ce qui est généralement bon signe, signifiant que tout le monde est d’accord avec l’idée — puisque personne n’a rien à dire qui s’y oppose), et le vote a été ouvert en fin de mois.

Stas Malyshev a corrigé le Bug #49348 : Uninitialized ++$foo->bar; does not cause a notice (but ++$bar; does!) ; à partir de PHP 5.5, utiliser une incrémentation sur une propriété inexistante, comme $this->undefined++, lévera une E_NOTICE — c’était déjà le cas pour les variables normales.

Nikita Popov a fait remarquer que si PHP 5.4 a introduit la syntaxe (new MaClass())->maMethode(), celle-ci ne fonctionne que pour new — et pas pour d’autres instructions, comme, par exemple, clone ; pour rendre les choses plus consistentes, il a proposé d’étendre cette syntaxe à n’importe quel type d’expression.

La proposition a semblé intéresser du monde, et n’a initialement pas réellement rencontré d’opposition ; le changement proposé semblait même suffisamment peu important pour que certains suggèrent de ne pas passer par les cases “RFC” et “vote” — suggestion qui, elle, a rencontré une certaine opposition (rédiger une RFC fait parti du processus, ça permet de mettre la nouvelle fonctionnalité au clair pour tout le monde, de pointer d’éventuels cas tordus, …) : après tout, il s’agirait de modifier le comportement du parseur, et ce type de changement peut avoir un impact sur de nombreux outils gravitant autour du langage (IDE, analyseurs de code source, …).

Comme l’a par la suite souligné Dmitry Stogov, cette modification peut avoir des impacts auxquels on ne pense pas immédiatement ; ce à quoi Stas Malyshev a fait remarquer qu’il ne fallait pas sortir cette nouvelle fonctionnalité trop vite.

La conversation s’est un peu essouflée en fin de mois, sans qu’aucune décision ne soit prise. Avec un peu de chance, on peut espérer qu’elle reprenne vie dans le futur, accompagnée d’une RFC.

Nikita Nefedov a fait remarquer qu’il pourrait être intéressant de supprimer le mot-clef function lors de la déclaration de méthodes dans des classes, interfaces, et traits — après tout, ce mot-clef est quelque peu redondant et n’apporte pas de réelle information en soit.

Comme l’a rapidement souligné Johannes Schlüter, ce n’est pas la première fois que le sujet est abordé sur internals@, et, il y plus de deux ans de cela, l’idée avait été abandonnée, le mot-clef function étant pratique pour, par exemple, rechercher des définitions de méthodes à coups de grep.

Dans l’ensemble, les retours semblent plutôt négatifs, entre les greppeurs, ceux qui considèrent qu’il faudrait arrêter de vouloir changer la syntaxe de PHP “juste pour faire joli”, ceux qui privilégient la lisibilité du code, et ceux qui soulignent que ce type de modification, même si sympathique, n’est pas réellement nécessaire⁴.

Finalement, considérant le peu d’intérêt pour cette idée et la forte opposition, la conversation s’est rapidement arrêtée, sans même atteindre l’étape “RFC”.

Keyur Govande a annoncé avoir rédigé la RFC: PHP CLI changing process title support, l’idée étant d’introduire une manière permettant de renseigner le titre d’un processus PHP lancé en ligne de commande — titre qui peut être visible, par exemple, en sortie des commandes ps ou top ; ceci serait particulièrement utile dans le cas de processus durant longtemps : il deviendrait plus facile de les identifier et de les différencier.

Même si l’utilité ne semblait pas évidente à tous au premier abord, plusieurs retours ont semblé montrer un certain intérêt, y compris parmis des utilisateurs de l’extension proctitle (qui, notamment, ne fonctionne pas sous Windows, et souffre de quelques bugs génants).

Après quelques échanges de mail, Keyur Govande a annoncé vouloir ouvrir la RFC au vote ; considérant qu’une seule journée de discussion était relativement peu, finalement, les votes n’ont pas été ouverts de suite, et ne l’ont été que quelques jours après.

Les choses ont l’air plutôt bien parties ; et on peut espérer qu’à la fin de la période de votes, soit début mars, cette modification soit intégrée à PHP 5.5.

Ivan Enderlin a ouvert un sujet de discussion où il faisait remarquer que PHP ne dispose pas d’un moyen unifié permettant à un script d’être tenu au courant de modifications apportées sur des fichiers — typiquement, pour effectuer une action dès qu’un fichier dans un ensemble de répertoires donné est modifié ; ce qui est parfois utile dans un contexte de scripts PHP durant longtemps et/ou en mode démon. Il suggère qu’une fonctionnalité de ce type, fonctionnant sous Windows/Mac/Linux, pourrait éventuellement avoir sa place dans le coeur de PHP.

Julien Pauli a répondu qu’une fonctionnalité de ce type n’aurait probablement pas sa place dans le core, mais que ceux qui en ressentaient le besoin avaient la possibilité d’utiliser une extension PECL (il existe par exemple l’extension inotiy, mais pour Linux uniquement). Il n’est d’ailleurs pas le seul à avoir répondu en ce sens.

D’après Patrick Allaert, une bonne approche serait de développer ceci sous forme d’une bibliothèque C — elle même ensuite mise à disposition de PHP via encapsulation dans une extension PECL.

Sara Golemon a rédigé la RFC: Trailing comma function args. L’idée proposée est d’autoriser la présence d’une virgule à la fin de la liste d’arguments lors d’un appel de fonction (de manière à ce que ma_fonction('plop', 'glop', ); soit syntaxiquement valide), de la même manière que c’est depuis toujours autorisé pour les déclarations de tableaux (comme $a = array('plop', 'glop', ); ).

Dans l’ensemble, l’idée a semblé être appréciée, notamment parce qu’elle implémenterait une syntaxe cohérente avec celle permise pour les tableaux, sans changer le comportement existant (si ce n’est autoriser une syntaxe qui ne l’était jusqu’à présent pas).

Cela dit, les retours n’ont pas tous été positifs ; comme l’a remarqué Alain Williams, autant il est fréquent d’ajouter un élément en fin de liste, autant il est plus rare d’effectuer ce type de modification sur un appel de fonction/méthode.

Dans la foulée, Marcello Duarte a annoncé avoir rédigé la RFC: Short syntax for anonymous functions. Dans l’ensemble, les retours semblent avoir été un peu plus négatifs sur celle-là, que ce soit parce que la syntaxe proposée ne plait pas, parce qu’elle introduit un risque de BC-break, ou parce que l’idée en elle-même ne semble pas nécessaire — sans compter le risque de nuire à la lisibilité du code. Cela dit, même sans forcément apprécier la syntaxe, d’autres ont visiblement apprécié la proposition, allant jusqu’à essayer de l’améliorer.

Paul Reinheimer a rédigé un mail à propos d’un sujet qui est revenu dans plusieurs discussions ces derniers mois : la majorité des développeurs utilisant PHP ne va pas à des conférences, ne lit pas internals@, et est finalement assez silencieuse. En conséquence, les développeurs de PHP peuvent parfois être quelque peu déconnectés de la réalité des utilisateurs du langage.

Une possibilité pour en savoir plus sur les besoins des différents types de développeurs travaillant avec PHP pourrait être de mettre en place un sondage — qui devrait être suffisamment réfléchi et construit de manière suffisamment scientifique pour qu’il soit possible d’en tirer des enseignements utiles.

Cela dit, Christopher Jones a fait remarquer que les choses pourraient / devraient aussi aller dans le sens inverse : pour lui, il faudrait que plus de membres de la communauté deviennent développeurs de PHP, et non plus “seulement” utilisateurs. Malheureusement, comme l’a rapidement noté Kris Craig, la plupart des développeurs utilisant PHP ne seraient pas forcément à l’aise avec du C.

Pour essayer de faire avancer les choses, Florin Razvan Patan a commencé à rédiger la RFC: Site voting poll. A voir comment cela évoluera sur les prochaines semaines ?

Et pour finir avec un peu d’humour, Aaron Holmes a fait remarquer que le XKCD 1172⁵ faisait beaucoup penser à ce qu’il se passe parfois avec PHP :

Crédits : XKCD #1172

En même temps, ce n’est pas loin de la vérité non plus…

J’ai fait un peu de Perl dans mon “jeune temps” ; c’était fun comme langage… et il y avait moyen de s’amuser avec sa syntaxe ^^ Par contre, sur des projets de la taille de ceux sur lesquels j’ai bossé ces dernières années… je craindrais ^^ ↩
Je simplifie peut-être un peu, au risque d’être caricatural — vous devinerez aisément de quel côté je me positionne ^^ ↩
Bon, aussi, utiliser eval() pour créer des fonctions anonymes… ↩
Forcément, en cours de route, la conversation a un peu déviée sur le nombre de développeurs qui utiliseraient grep pour rechercher des fonctions, ceux qui travaillent avec un IDE, ceux qui ne savent même pas ce qu’est grep, ou encore ceux qui considèrent que Linux est un IDE… ↩
Oui, je fais parti de ceux qui apprécient XKCD et ont tendance à y faire référence ici et là ;-) ↩

Aller plus loin avec un dump des opcodes d'un script PHP

Pascal MARTIN — Thu, 21 Feb 2013 07:00:00 +0100

J’ai publié il y a quelques jours un article expliquant comment obtenir un dump des opcodes d’un script PHP, en utilisant l’extension VLD - Vulcan Logic Dumper.

Pour le compléter et aller un peu plus loin, je vais maintenant montrer comment obtenir un graphe des chemins correspondant à un dump d’opcodes — et donc, au code PHP initialement écrit.

Et en seconde partie de cet article, je me baserai sur quelques dumps d’opcodes pour montrer que, des fois, mettre à jour PHP est une bonne idée ;-)

Quelques options plus avancées de VLD : dump de chemins / branches

En plus de la simple fonctionnalité de dump d’opcodes, l’extension VLD¹ propose quelques options supplémentaires :

L’option vld.dump_paths permet d’activer un dump des chemins et branches d’exécution du code PHP,
L’option vld.save_paths permet d’enregistrer ce dump supplémentaire vers le fichier /tmp/paths.dot (format qui peut être utilisé avec graphviz),
Et enfin, l’option vld.save_dir permet de spécifier un autre répertoire vers lequel enregistrer ce fichier.

A titre d’exemple, considérons la portion de code PHP suivante :

<?php
$tmp = mt_rand(0, 2);
if ($tmp === 0) {
    echo "zero";
}
else if ($tmp === 1) {
    echo "un";
}
else {
    echo "deux";
}
echo "\n";

Rien de bien particulier : un bloc if / else if / else, avec quelques sorties écran.

Maintenant, utilisons VLD pour générer un dump des opcodes correspondant à ce script, ainsi que le dump des chemins correspondant — dump qui sera enregistré vers l’emplacement par défaut, /tmp/paths.dot :

$ ~/bin/php-5.3/bin/php -dextension=vld.so -dvld.active=1 -dvld.verbosity=0 -dvld.execute=0 -dvld.dump_paths=1 -dvld.save_paths=1 exemples/005-dump-paths-1.php 
filename:       /.../exemples/005-dump-paths-1.php
function name:  (null)
number of ops:  15
compiled vars:  !0 = $tmp
line     # *  op                           fetch          ext  return  operands
---------------------------------------------------------------------------------
   2     0  >   SEND_VAL                                                 0
         1      SEND_VAL                                                 2
         2      DO_FCALL                                      2  $0      'mt_rand'
         3      ASSIGN                                                   !0, $0
   3     4      IS_IDENTICAL                                     ~2      !0, 0
         5    > JMPZ                                                     ~2, ->8
   4     6  >   ECHO                                                     'zero'
   5     7    > JMP                                                      ->13
   6     8  >   IS_IDENTICAL                                     ~3      !0, 1
         9    > JMPZ                                                     ~3, ->12
   7    10  >   ECHO                                                     'un'
   8    11    > JMP                                                      ->13
  10    12  >   ECHO                                                     'deux'
  12    13  >   ECHO                                                     '%0A'
  13    14    > RETURN                                                   1

branch: #  0; line:     2-    3; sop:     0; eop:     5; out1:   6; out2:   8
branch: #  6; line:     4-    5; sop:     6; eop:     7; out1:  13
branch: #  8; line:     6-    6; sop:     8; eop:     9; out1:  10; out2:  12
branch: # 10; line:     7-    8; sop:    10; eop:    11; out1:  13
branch: # 12; line:    10-   12; sop:    12; eop:    12; out1:  13
branch: # 13; line:    12-   13; sop:    13; eop:    14
path #1: 0, 6, 13, 
path #2: 0, 8, 10, 13, 
path #3: 0, 8, 12, 13,

le fichier /tmp/paths.dot est bien généré en sortie :

$ ll /tmp/paths.dot 
-rw-r--r-- 1 squale squale 711 janv.  3 15:25 /tmp/paths.dot

Et, pour les curieux, voici à quoi il ressemble :

$ cat /tmp/paths.dot
digraph {
subgraph cluster_file_01471438 { label="file /.../exemples/005-dump-paths-1.php";
subgraph cluster_01471438 {
        label="__main";
        graph [rankdir="LR"];
        node [shape = record];
        "__main_0" [ label = "{ op #0 | line 2-3 }" ];
        __main_0 -> __main_6;
        __main_0 -> __main_8;
        "__main_6" [ label = "{ op #6 | line 4-5 }" ];
        __main_6 -> __main_13;
        "__main_8" [ label = "{ op #8 | line 6-6 }" ];
        __main_8 -> __main_10;
        __main_8 -> __main_12;
        "__main_10" [ label = "{ op #10 | line 7-8 }" ];
        __main_10 -> __main_13;
        "__main_12" [ label = "{ op #12 | line 10-12 }" ];
        __main_12 -> __main_13;
        "__main_13" [ label = "{ op #13 | line 12-13 }" ];
}
}
}

A partir du fichier .dot généré par VLD, il est possible de générer un .png, en utilisant l’outil dot de graphviz :

dot -Tpng /tmp/paths.dot > /tmp/paths.png

Ce qui nous donne en sortie une image de ce type (j’ai supprimé le nom du fichier qui figurait normalement en haut de l’image, pour réduire un peu ses dimensions) :

On retrouve, à partir des opcodes, la structure de notre script — et ce graphe de chemins peut faciliter la compréhension du dump d’opcodes brutes, en particulier dans des cas de scripts / fonctions plus longs que l’exemple que j’ai pris ici.

D’ailleurs, en générant le graphe de chemins pour l’exemple utlisé à la section “Un peu de structures conditionnelles / boucles” de mon précédent article, voici ce que l’on obtient :

Utiliser ceci en parallèle des explications textuelles données un peu plus haut devrait vous aider à y voir plus clair ;-)

Opcodes : des différences entre les versions de PHP ?

Chaque nouvelle version de PHP vient avec son lot de modifications, d’améliorations, et d’optimisations.

Certaines d’entre elles peuvent parfois porter sur le processus de compilation de code PHP en opcodes — l’idée générale, un peu simplifiée certes, étant que moins il y a d’opcodes à exécuter, plus cette exécution devrait être rapide.

Bien entendu, il ne faut pas s’attendre à ce que les opcodes générées pour une portion de script PHP changent du tout au tout entre deux versions de PHP… Mais, voici quelques exemples courts, sur lesquels on constate de petites différences.

Premier exemple

Tout d’abord, prenons la portion de code suivante :

<?php
$who = 'World';
$str = "Hello, $who!";
echo $str;

En quelques mots : on utilise l’interpolation de variables pour combiner deux chaines de caractères, et on affiche la chaîne résultante — oui, encore un Hello, World.

Avec PHP 5.3 et PHP 5.4, la sortie obtenue en utilisant VLD est la suivante :

$ ~/bin/php-5.4/bin/php -dextension=vld.so -dvld.active=1 -dvld.verbosity=0 -dvld.execute=0 exemples/010-diff-versions-php-1.php 
filename:       /.../exemples/010-diff-versions-php-1.php
function name:  (null)
number of ops:  7
compiled vars:  !0 = $who, !1 = $str
line     # *  op                           fetch          ext  return  operands
---------------------------------------------------------------------------------
   2     0  >   ASSIGN                                                   !0, 'World'
   3     1      ADD_STRING                                       ~1      'Hello%2C+'
         2      ADD_VAR                                          ~1      ~1, !0
         3      ADD_CHAR                                         ~1      ~1, 33
         4      ASSIGN                                                   !1, ~1
   4     5      ECHO                                                     !1
   5     6    > RETURN                                                   1

branch: #  0; line:     2-    5; sop:     0; eop:     6
path #1: 0,

Par contre, avec PHP 5.2.17, la sortie est la suivante :

$ ~/bin/php-5.2/bin/php -dextension=vld.so -dvld.active=1 -dvld.verbosity=0 -dvld.execute=0 exemples/010-diff-versions-php-1.php 
filename:       /.../exemples/010-diff-versions-php-1.php
function name:  (null)
number of ops:  9
compiled vars:  !0 = $who, !1 = $str
line     # *  op                           fetch          ext  return  operands
---------------------------------------------------------------------------------
   2     0  >   ASSIGN                                                   !0, 'World'
   3     1      INIT_STRING                                      ~1      
         2      ADD_STRING                                       ~1      ~1, 'Hello%2C+'
         3      ADD_VAR                                          ~1      ~1, !0
         4      ADD_CHAR                                         ~1      ~1, 33
         5      ASSIGN                                                   !1, ~1
   4     6      ECHO                                                     !1
   5     7    > RETURN                                                   1
         8*   > ZEND_HANDLE_EXCEPTION                                    

branch: #  0; line:     2-    5; sop:     0; eop:     8
path #1: 0,

La compilation de nos trois lignes de code PHP mène à 2 opcodes de plus avec PHP 5.2 qu’avec PHP 5.3 :

Un opcode INIT_STRING, en seconde instruction,
et un opcode ZEND_HANDLE_EXCEPTION en toute dernière ligne — opcode qui ne sera jamais exécuté, d’ailleurs (VLD l’a marqué d’une *) : il est positionné après un RETURN.

En remontant un peu plus loin dans l’histoire, avec PHP 5.1.6, nous aurions obtenu encore plus d’opcodes :

$ ~/bin/php-5.1/bin/php -dextension=vld.so -dvld.active=1 -dvld.verbosity=0 -dvld.execute=0 exemples/010-diff-versions-php-1.php 
filename:       /.../exemples/010-diff-versions-php-1.php
function name:  (null)
number of ops:  10
compiled vars:  !0 = $who, !1 = $str
line     # *  op                           fetch          ext  return  operands
---------------------------------------------------------------------------------
   2     0  >   ASSIGN                                                   !0, 'World'
   3     1      INIT_STRING                                      ~1      
         2      ADD_STRING                                       ~1      ~1, 'Hello'
         3      ADD_STRING                                       ~1      ~1, '%2C+'
         4      ADD_VAR                                          ~1      ~1, !0
         5      ADD_STRING                                       ~1      ~1, '%21'
         6      ASSIGN                                                   !1, ~1
   4     7      ECHO                                                     !1
   5     8    > RETURN                                                   1
         9*   > ZEND_HANDLE_EXCEPTION                                    

branch: #  0; line:     2-    5; sop:     0; eop:     9
path #1: 0,

Ce n’est pas vraiment mis en évidence ici, puisque la chaine de caractères utilisant de l’interpolation de variables n’est pas très longue, mais PHP 5.1 générait un opcode ADD_STRING pour chaque ensemble de caractères séparés par un espace !
Vous pourriez faire le test avec une chaine comme "Voici une $var plus longue.", qui nécessite 11 opcodes en PHP 5.1 — et seulement 3 en PHP 5.4.

Que tirer de ceci ?

Avec PHP 5.1, utiliser des chaines de caractères entourées de double-quotes, avec de l’interpolation de variables, n’était vraiment pas fantastique au niveau du nombre d’opcodes générés — c’est probablement un peu de là que vient la (il fût un temps micro-optimisation / ) généralisation un peu sauvage en “utilisez des chaines de caractères entre simple-quotes”.
Mais PHP 5.2 a déjà grandement amélioré les choses, rendant quasiment obsolète cette affirmation — du moins sur des cas tels que celui présenté ici.
Et PHP 5.3 a encore amélioré ce cas.

Autrement dit, la meilleure “optimisation” que vous puissiez faire — et qui n’est même pas de la “micro”-optimisation vu les benchs — est d’utiliser une version à jour de PHP !

Second exemple

Comme second exemple, considérons la portion de code suivante, qui définit une fonction, et l’appelle en affichant sa valeur de retour :

<?php
function add($val1, $val2)
{
    return $val1 + $val2;
}

echo test(10, 5);

Avec PHP 5.4, la sortie obtenue avec VLD est la suivante :

$ ~/bin/php-5.4/bin/php -dextension=vld.so -dvld.active=1 -dvld.verbosity=0 -dvld.execute=0 exemples/010-diff-versions-php-2.php 
filename:       /.../exemples/010-diff-versions-php-2.php
function name:  (null)
number of ops:  7
compiled vars:  none
line     # *  op                           fetch          ext  return  operands
---------------------------------------------------------------------------------
   2     0  >   NOP                                                      
   7     1      INIT_FCALL_BY_NAME                                       'test'
         2      SEND_VAL                                                 10
         3      SEND_VAL                                                 5
         4      DO_FCALL_BY_NAME                              2  $0      
         5      ECHO                                                     $0
   8     6    > RETURN                                                   1

branch: #  0; line:     2-    8; sop:     0; eop:     6
path #1: 0, 
Function add:
filename:       /.../exemples/010-diff-versions-php-2.php
function name:  add
number of ops:  5
compiled vars:  !0 = $val1, !1 = $val2
line     # *  op                           fetch          ext  return  operands
---------------------------------------------------------------------------------
   2     0  >   RECV                                             !0      
         1      RECV                                             !1      
   4     2      ADD                                              ~0      !0, !1
         3    > RETURN                                                   ~0
   5     4*   > RETURN                                                   null

branch: #  0; line:     2-    5; sop:     0; eop:     4
path #1: 0, 
End of function add.

En premier, nous avons la définition de la fonction ; et ensuite, son appel.

Avec PHP 5.2, nous aurions la sortie suivante :

$ ~/bin/php-5.2/bin/php -dextension=vld.so -dvld.active=1 -dvld.verbosity=0 -dvld.execute=0 exemples/010-diff-versions-php-2.php 
filename:       /.../exemples/010-diff-versions-php-2.php
function name:  (null)
number of ops:  8
compiled vars:  none
line     # *  op                           fetch          ext  return  operands
---------------------------------------------------------------------------------
   2     0  >   NOP                                                      
   7     1      INIT_FCALL_BY_NAME                                       'test'
         2      SEND_VAL                                                 10
         3      SEND_VAL                                                 5
         4      DO_FCALL_BY_NAME                              2  $0      
         5      ECHO                                                     $0
   8     6    > RETURN                                                   1
         7*   > ZEND_HANDLE_EXCEPTION                                    

branch: #  0; line:     2-    8; sop:     0; eop:     7
path #1: 0, 
Function add:
filename:       /.../exemples/010-diff-versions-php-2.php
function name:  add
number of ops:  6
compiled vars:  !0 = $val1, !1 = $val2
line     # *  op                           fetch          ext  return  operands
---------------------------------------------------------------------------------
   2     0  >   RECV                                                     1
         1      RECV                                                     2
   4     2      ADD                                              ~0      !0, !1
         3    > RETURN                                                   ~0
   5     4*     RETURN                                                   null
         5*   > ZEND_HANDLE_EXCEPTION                                    

branch: #  0; line:     2-    5; sop:     0; eop:     5
path #1: 0, 
End of function add.

En somme, cette fois-ci, peu de différence : on notera juste la présence d’une opcode ZEND_HANDLE_EXCEPTION inutile à la fin de chacun des deux extraits, avec PHP 5.2.

Arrivés à la fin de ce second article sur les opcodes de PHP, j’espère avoir réussi à attirer votre curiosité : c’était le but² ^^

Je n’ai pas du tout parlé de la phase d’exécution de ces opcodes, qui correspond réellement à l’exécution d’un script PHP (la génération des opcodes correspondant à la compilation du PHP) ; si vous êtes joueur et avez envie d’en apprendre plus, je vous encourage à ouvrir le fichier Zend/zend_vm_def.h, qui fait parti des sources de PHP : vous y trouverez la définition de chaque opcode géré par le moteur d’exécution de PHP.

Je ne reviens par dans cet article sur l’installation de l’extension VLD, ni son fonctionnement de base ; en cas de besoin, je vous encourage à lire l’article Obtenir un dump des opcodes d’un script PHP que j’ai publié il y a quelques jours. ↩
Autant le sujet des opcodes peut attirer notre curiosité, du point de vue d’un développeur purement “PHP”, il est somme toute plus que rare que nous ayons à nous en soucier… ↩

Obtenir un dump des opcodes d'un script PHP

Pascal MARTIN — Mon, 18 Feb 2013 07:00:00 +0100

Lors de l’exécution d’un script PHP, l’interpréteur PHP passe par deux étapes :

Tout d’abord, le script écrit en langage PHP est compilé en opcodes,
Puis ces opcodes sont exécutés.

Basiquement, les opcodes sont des instructions simples ; nettement plus, en tout cas, que le langage PHP que nous écrivons.

Dans notre vie de tous les jours, savoir que ce processus PHP -> opcodes -> exécution existe est utile : il nous permet par exemple de comprendre l’utilité d’un cache d’opcodes comme APC. Mais, heureusement, il est rare que nous ayons à nous pencher sur les opcodes en eux-même.

Cela dit, pour les plus curieux d’entre nous¹, il existe des extensions PHP permettant d’obtenir la liste des opcodes correspondant à un script PHP.

Installation de VLD

L’extension VLD - Vulcan Logic Dumper est généralement celle à laquelle je pense à premier, lorsque je veux obtenir un dump des opcodes correspondant à un script PHP.

Il s’agit d’une extension PECL, qui s’installe comme n’importe quelle autre extension du genre, via la commande pecl install :

~/bin/php-5.3/bin/pecl install vld
downloading vld-0.11.2.tgz ...
Starting to download vld-0.11.2.tgz (16,403 bytes)

Cette extension étant en bêta², si vous n’avez sélectionné le channel par défaut, vous aurez peut-être à utiliser :

~/bin/php-5.3/bin/pecl install vld-beta
downloading vld-0.11.2.tgz ...
Starting to download vld-0.11.2.tgz (16,403 bytes)

Et pour vérifier que l’extension se charge, elle doit apparaitre en sortir d’un php -m, à partir du moment où extension=vld.so est spécifié comme option :

$ ~/bin/php-5.3/bin/php -dextension=vld.so -m
[PHP Modules]
bcmath
bz2
calendar
...
tokenizer
vld
xml
...

L’autre solution serait d’ajouter extension=vld.so à votre fichier php.ini ou à un des fichiers interprétés par PHP — mais je n’ai pas tendance à le faire pour cette extension, puisque je ne souhaite la charger que très rarement, et pas “par défaut”.

Obtenir un premier dump d’opcodes

Une fois l’extension VLD installée, il va nous être possible d’obtenir un dump d’opcodes pour un script PHP.

Par exemple, considérons le script PHP suivant — qui est des plus simples, vous l’admettrez :

<?php
echo "Hello, World";

Pour obtenir la liste des opcodes correspondant à ce script, PHP doit être invoqué en ligne de commandes, en chargeant l’extension VLD (-dextension=vld.so), et en lui spécifiant qu’elle doit être active (-dvld.active=1) :

$ ~/bin/php-5.3/bin/php -dextension=vld.so -dvld.active=1 exemples/001-hello-world.php 
Finding entry points
Branch analysis from position: 0
Return found
filename:       /.../exemples/001-hello-world.php
function name:  (null)
number of ops:  2
compiled vars:  none
line     # *  op                           fetch          ext  return  operands
---------------------------------------------------------------------------------
   2     0  >   ECHO                                                     'Hello%2C+World'
   3     1    > RETURN                                                   1

branch: #  0; line:     2-    3; sop:     0; eop:     1
path #1: 0, 
Hello, World

Il est possible de jouer avec la verbosité pour obtenir une sortie plus ou moins riche, en utilisant l’option vld.verbosity, qui vaut 1 par défaut. Il est possible de la baisser à 0, ou l’augmenter — une valeur de 3, par exemple, ajoute des informations portant sur les types de données manipulées.

L’option vld.execute est dans certains cas intéressante, puisqu’elle permet d’éviter l’exécution du code PHP — afin de n’obtenir en sortie que les opcodes, et pas les affichages provoqués par le script.

En jouant avec les options vld.verbosity et vld.execute, voici un exemple de sortie que nous pourrions obtenir :

$ ~/bin/php-5.3/bin/php -dextension=vld.so -dvld.active=1 -dvld.verbosity=0 -dvld.execute=0 exemples/001-hello-world.php 
filename:       /.../exemples/001-hello-world.php
function name:  (null)
number of ops:  2
compiled vars:  none
line     # *  op                           fetch          ext  return  operands
---------------------------------------------------------------------------------
   2     0  >   ECHO                                                     'Hello%2C+World'
   3     1    > RETURN                                                   1

branch: #  0; line:     2-    3; sop:     0; eop:     1
path #1: 0,

Nous n’avons pas, cette fois-ci, obtenu l’affichage du "Hello, World" ; et moins d’informations sont affichées autour de la liste des opcodes.

Des exemples avec des scripts PHP plus longs ?

Nous avons vu juste au-dessus que l’extension VLD nous permettait d’obtenir un dump des opcodes correspondant à un script PHP.

Cela dit, un “Hello, World” n’est pas forcément l’exemple le plus intéressant… Passons donc à quelque chose d’un peu plus complet !

Avec une déclaration et un appel de fonction

Tout d’abord, prenons un exemple où nous déclarons une fonction, et l’appelons en lui passant un paramètre — pour ensuite afficher la valeur retournée :

<?php
function hello($who) {
    return sprintf("Hello, %s!", $who);
}

echo hello('World');

La sortie renvoyée par VLD pour ce script est la suivante :

$ ~/bin/php-5.3/bin/php -dextension=vld.so -dvld.active=1 -dvld.verbosity=0 -dvld.execute=0 exemples/003-function.php 
filename:       /.../exemples/003-function.php
function name:  (null)
number of ops:  5
compiled vars:  none
line     # *  op                           fetch          ext  return  operands
---------------------------------------------------------------------------------
   2     0  >   NOP                                                      
   6     1      SEND_VAL                                                 'World'
         2      DO_FCALL                                      1  $0      'hello'
         3      ECHO                                                     $0
   7     4    > RETURN                                                   1

branch: #  0; line:     2-    7; sop:     0; eop:     4
path #1: 0, 
Function hello:
filename:       /.../exemples/003-function.php
function name:  hello
number of ops:  6
compiled vars:  !0 = $who
line     # *  op                           fetch          ext  return  operands
---------------------------------------------------------------------------------
   2     0  >   RECV                                                     1
   3     1      SEND_VAL                                                 'Hello%2C+%25s%21'
         2      SEND_VAR                                                 !0
         3      DO_FCALL                                      2  $0      'sprintf'
         4    > RETURN                                                   $0
   4     5*   > RETURN                                                   null

branch: #  0; line:     2-    4; sop:     0; eop:     5
path #1: 0, 
End of function hello.

Cette sortie se découpe en deux portions :

L’appel de notre fonction,
Et ensuite, sa déclaration.

En essayant de formuler en français ce que la portion correspondant à l’appel de la fonction fait, nous aurions :

Tout d’abord, la valeur 'Hello' est envoyée,
Puis, la fonction 'hello' est appelée ; sa valeur de retour étant stockée dans $0,
Cette valeur $0 est alors affichée,
Et enfin, le script se termine avec un retour à 1.

Et pour la déclaration de la fonction hello(), maintenant :

Tout d’abord, notre fonction reçoit un paramètre,
Puis elle empile la chaine "Hello, %s!" — celle que nous passons en premier paramètre à sprintf(),
Après quoi elle empile le second paramètre passé à la fonction sprintf() — qui est le premier paramètre reçu en argument par notre fonction : !0 que nous avions nommé $who dans le code PHP (Cette correspondance entre !0 et $who est indiquée au-dessus de la liste d’opcodes de la fonction, dans la section compiled vars),
Pour ensuite appeler fonction sprintf(), en stockant sa valeur de retour dans $0,
Et cette valeur de retour de sprintf(), $0, sera elle-même retournée par notre fonction.
On notera que la liste d’opcodes de cette fonction se termine par deux opcodes RETURN ; le second, qui aurait retourné null, ne sera jamais exécuté (puisqu’il est précédé du RETURN $0), et est donc marqué d’une * par VLD.

Et une classe, alors ?

Une question, qu’on aura parfois tendance à se poser après avoir vu l’exemple précédent, tourne autour des classes : “mais comment est-ce que ça marche pour une classe et des méthodes ?”. Je serais tenté de répondre que la meilleure façon de savoir est d’essayer ; avec une portion de code telle que celle que je reproduis ci-dessous :

<?php
class MaClasse {
    protected $prop;
    public function __construct($valeur) {
        $this->prop = $valeur;
    }
    public function add($valeur) {
        $this->prop += $valeur;
    }
    public function getValeur() {
        return $this->prop;
    }
}

$obj = new MaClasse(32);
$obj->add(10);
$result = $obj->getValeur();
echo $result;

La sortie obtenue via l’extension VLD est relativement longue ; et je ne vais pas la reproduire d’un seul trait ; voici ce que nous obtenons pour le script — pour le code en dehors de la classe, les quelques lignes en bas de l’exemple de code PHP reproduit ci-dessus :

$ ~/bin/php-5.3/bin/php -dextension=vld.so -dvld.active=1 -dvld.verbosity=0 -dvld.execute=0 exemples/003-classe.php 
filename:       /.../exemples/003-classe.php
function name:  (null)
number of ops:  14
compiled vars:  !0 = $obj, !1 = $result
line     # *  op                           fetch          ext  return  operands
---------------------------------------------------------------------------------
   2     0  >   NOP                                                      
  15     1      ZEND_FETCH_CLASS                              4  :1      'MaClasse'
         2      NEW                                              $2      :1
         3      SEND_VAL                                                 32
         4      DO_FCALL_BY_NAME                              1          
         5      ASSIGN                                                   !0, $2
  16     6      ZEND_INIT_METHOD_CALL                                    !0, 'add'
         7      SEND_VAL                                                 10
         8      DO_FCALL_BY_NAME                              1          
  17     9      ZEND_INIT_METHOD_CALL                                    !0, 'getValeur'
        10      DO_FCALL_BY_NAME                              0  $8      
        11      ASSIGN                                                   !1, $8
  18    12      ECHO                                                     !1
  19    13    > RETURN                                                   1

Je vous laisse parcourir ces 14 opcodes pour essayer de les comprendre ; dans les grandes lignes, une classe est chargée via ZEND_FETCH_CLASS, puis instanciée à l’aide de NEW, après quoi son constructeur est appelé (instruction 4, avec DO_FCALL_BY_NAME). Les méthodes add() et getValeur() sont ensuite invoquées, en stockant la valeur de retour de la seconde dans $result, qui finit par être affichée.

Viennent ensuite les listes d’opcodes de chacune des méthodes de la classe, qui constituent autant de sous-ensembles que l’on pourrait considérer comme indépendant.
Commençons par le constructeur :

Class MaClasse:
Function __construct:
filename:       /.../exemples/003-classe.php
function name:  __construct
number of ops:  4
compiled vars:  !0 = $valeur
line     # *  op                           fetch          ext  return  operands
---------------------------------------------------------------------------------
   4     0  >   RECV                                                     1
   5     1      ZEND_ASSIGN_OBJ                                          'prop'
         2      ZEND_OP_DATA                                             !0
   6     3    > RETURN                                                   null

branch: #  0; line:     4-    6; sop:     0; eop:     3
path #1: 0, 
End of function __construct.

Simplement, la valeur reçue en paramètre, via la variable $valeur ici désignée par !0, est assignée à la propriété prop.

Suit la définition de la méthode add(), qui ajoute à prop la valeur reçue via le paramètre $valeur, ici aussi désigné par !0 :

Function add:
filename:       /.../exemples/003-classe.php
function name:  add
number of ops:  4
compiled vars:  !0 = $valeur
line     # *  op                           fetch          ext  return  operands
---------------------------------------------------------------------------------
   7     0  >   RECV                                                     1
   8     1      ASSIGN_ADD                                   88          'prop'
         2      ZEND_OP_DATA                                             !0
   9     3    > RETURN                                                   null

branch: #  0; line:     7-    9; sop:     0; eop:     3
path #1: 0, 
End of function add.

Et, finalement, la dernière méthode de notre classe, getValeur(), qui charge la valeur de la propriété prop et la retourne à l’appelant :

Function getvaleur:
filename:       /.../exemples/003-classe.php
function name:  getValeur
number of ops:  3
compiled vars:  none
line     # *  op                           fetch          ext  return  operands
---------------------------------------------------------------------------------
  11     0  >   FETCH_OBJ_R                                      $0      'prop'
         1    > RETURN                                                   $0
  12     2*   > RETURN                                                   null

branch: #  0; line:    11-   12; sop:     0; eop:     2
path #1: 0, 
End of function getvaleur.

End of class MaClasse.

Pour une quinzaine de lignes de code PHP, ça représente un bon paquet de lignes en sortant de VLD, n’est-ce pas ? Mais, malgrés tout, à condition de ne pas prendre peur devant tous ces opcodes, cette sortie reste globalement compréhensible, non ?

Un peu de structures conditionnelles / boucles

Pour illustrer le type d’enchainements d’opcodes correspondant à des boucles et conditions, prenons l’exemple de la portion de code suivante (qui pourrait être écrite de façon un peu plus concise, j’en conviens) :

<?php
for ($i=0 ; $i<10 ; $i++) {
    if ($i % 2 === 0) {
        echo "Pair : ";
    }
    else {
        echo "Impair : ";
    }
    echo $i, "\n";
}

Avec un niveau de verbosité à 0, la sortie obtenue avec VLD est la suivante :

$ ~/bin/php-5.3/bin/php -dextension=vld.so -dvld.active=1 -dvld.verbosity=0 -dvld.execute=0 exemples/003-control.php 
filename:       /.../exemples/003-control.php
function name:  (null)
number of ops:  16
compiled vars:  !0 = $i
line     # *  op                           fetch          ext  return  operands
---------------------------------------------------------------------------------
   2     0  >   ASSIGN                                                   !0, 0
         1  >   IS_SMALLER                                       ~1      !0, 10
         2    > JMPZNZ                                        6          ~1, ->15
         3  >   POST_INC                                         ~2      !0
         4      FREE                                                     ~2
         5    > JMP                                                      ->1
   3     6  >   MOD                                              ~3      !0, 2
         7      IS_IDENTICAL                                     ~4      ~3, 0
         8    > JMPZ                                                     ~4, ->11
   4     9  >   ECHO                                                     'Pair+%3A+'
   5    10    > JMP                                                      ->12
   7    11  >   ECHO                                                     'Impair+%3A+'
   9    12  >   ECHO                                                     !0
        13      ECHO                                                     '%0A'
  10    14    > JMP                                                      ->3
  11    15  > > RETURN                                                   1

branch: #  0; line:     2-    2; sop:     0; eop:     0; out1:   1
branch: #  1; line:     2-    2; sop:     1; eop:     2; out1:  15; out2:   6
branch: #  3; line:     2-    2; sop:     3; eop:     5; out1:   1
branch: #  6; line:     3-    3; sop:     6; eop:     8; out1:   9; out2:  11
branch: #  9; line:     4-    5; sop:     9; eop:    10; out1:  12
branch: # 11; line:     7-    9; sop:    11; eop:    11; out1:  12
branch: # 12; line:     9-   10; sop:    12; eop:    14; out1:   3
branch: # 15; line:    11-   11; sop:    15; eop:    15
path #1: 0, 1, 15, 
path #2: 0, 1, 6, 9, 12, 3, 1, 15, 
path #3: 0, 1, 6, 11, 12, 3, 1, 15,

Cela peut sembler être un peu cryptique si on regarde de loin, avec des sauts dans tous les sens³, mais, finalement, c’est “juste” la transcription de la portion de code que nous avons écrite — celle-ci pourrait être lu de la manière suivante :

Instruction 0 : On assigne 0 à la variable $i ; qui est représentée par !0, comme indiqué dans la section compiled vars.
Instruction 1 : “Est-ce que $i est inférieur à 10” est stocké dans ~1.
Instruction 2 :
- Si ~1 est faux, on saute vers l’instruction 15 (cf seconde colonne, celle titrée “#”), marquant ainsi la fin de la boucle.
- Sinon, on saute vers l’instruction 6 (on entre dans le corps de la boucle for, autrement dit — en passant après les opcodes 3 à 5 qui correspondent à l’operation du for, et au retour au début, au test de la condition).
Instruction 3 : on post-incrémente $i, et on stocke le résultat de cette post-incrémentation dans ~2 ; c’est l’opération effectuée en troisième partie de la boucle for.
Instruction 4 : on libère ~2, qui correspond au résultat de la post-incrémentation de $i ; dans la pratique, stocker ce résultat lors de l’instruction 3 a été complètement inutile, puisque nous le libérons immédiatement après.
Instruction 5 : on saute vers l’instruction 1 ; en somme, après avoir incrémenté $i, nous revenons au test de la condition ; nous bouclons.
Instruction 6 : on calcule le modulo 2 de $i, et stocke le résultat dans ~3 ; nous sommes à l’intérieur du corps de la structure for.
Instruction 7 : on teste si ~3, le résultat de ce modulo, est identique (égalité stricte avec l’opérateur ===) à 0, et stocke le résultat de la comparaison dans ~4.
Instruction 8 : si ~4 est faux (le résultat du modulo n’est pas égal à 0 ; $i est donc un nombre impair), on saute vers l’instruction 11.
Instruction 9 : on affiche "Pair : " ; on est dans le corps du if.
Instruction 10 : on saute vers l’instruction 12 ; nous sommes arrivés à la fin du corps du if, et sautons après le corps du else, pour ne pas l’exécuter.
Instruction 11 : on affiche "Impair : " ; on est dans le corps du else.
Instruction 12 : on affiche la valeur de $i ; on est après l’intégralité de la construction if/else.
Instruction 13 : on affiche un retour à la ligne.
Instruction 14 : on saute vers l’instruction 3 ; vers l’opération de post-incrémentation de $i, effectuée en troisième partie de la construction for.
Instruction 15 : c’est la fin du script.

Cela devrait vous aider à comprendre l’enchainement logique des quelques lignes d’opcodes reproduites ci-dessus ;-)

D’autres extensions ?

Pour cet article, j’ai choisi de parler quasi-exclusivement de l’extension VLD.

Cela dit, il existe d’autres extensions qui permettent d’accéder aux opcodes d’un script PHP.
Je pense notamment aux extensions Bytekit et Parsekit.

La première, Bytekit, dont on peut trouver les sources sur github, est connue en partie gràce à l’outil bytekit-cli ; cet utilitaire en ligne de commande permet d’utiliser l’extension Bytekit pour effectuer certains types d’analyses de code, comme la détection d’utilisation de certains opcodes.

La seconde, Parsekit, est disponible sur PECL, et exporte au code PHP quelques fonctions qui permettent d’obtenir des listes d’opcodes correspondant à du code PHP, depuis un script PHP.

Cela dit, ces deux extensions ne me semblent plus tellement maintenues :

Pour Bytekit, les sources que l’on trouve sur github semblent correspondre à une copie de la dernière version “officiellement publiée” des sources : elles ont été importées vers github en mai 2011, et jamais modiées depuis — le site officiel n’existe plus, d’ailleurs.
Et pour Parsekit, la dernière version a été diffusée en 2009 ; la précédente remontant à 2006.

Voila pourquoi j’ai préféré parler de VLD tout au long de cet article, cette extension ayant été mise à jour pour la dernière fois suite à la sortie de PHP 5.4.

Liens :

Sur le blog de Sara Golemon, quelques articles de 2006-2008 sur le sujet des opcodes :
A propos de l’extension VLD :
- VLD : la page du package sur PECL
- VLD - Vulcan Logic Dumper : la page du projet sur le site de Derick Rethans, son auteur (aussi auteur de l’extension Xdebug)
- More source analysis with VLD
D’autres extensions et outils :
- Bytekit
- bytekit-cli : les sources de bytekit-cli, sur github
- bytekit-cli : la présentation de l’outil bytekit-cli par son auteur, Sebastian Bergmann.
- Parsekit sur PECL ; et la section correspondante du manuel.

Au cours de cet article, nous avons vu comment installer l’extension VLD pour obtenir un dump des opcodes correspondant à un script PHP. Nous avons aussi étudié les dumps correspondant à des exemples relativement simples, afin de comprendre leur structure et de nous familiariser avec les opcodes, leur syntaxe, et la logique de leur enchainement.

Dans quelques jours, je publierai un second article sur le sujet des opcodes, où je montrerai comment utiliser VLD pour obtenir un graphe des chemins correspondant à un dump d’opcodes — et donc, au code PHP initialement écrit.

Et je profiterai de l’occasion pour montrer que, des fois, mettre à jour PHP est une bonne idée ;-)

Et peut-être ceux qui ont eu la chance de faire un peu d’Assembleur dans leur jeune temps ? Et qui regretteraient cette bonne vieille époque ? ↩
L’extension VLD n’a jamais été marquée comme “stable”, je serais presque tenté de supposer que c’est fait exprès pour décourager ceux qui voudraient l’installer en production (chose que, bien évidemment, vous n’avez pas à faire ^^). ↩
A chaque fois que je vois un truc qui ressemble à ça, je ne peux m’empêcher de l’époque où j’ai eu l’occasion d’écrire un peu d’Assembleur Motorola 68000 — et, surtout, de lire celui que GCC générait lorsque je compilais du code C à destination de ma TI-92+, et que je voulais comprendre quelle écriture C donnait le code assembleur le plus efficace (Sur 10 MHz, pour arriver à avoir un FPS raisonable, il fallait optimiser ; pas d’autre solution ^^).
Je n’en referais pas dans “la vie de tous les jours”, mais le petit sentiment de nostalgie est bien présent : après, qu’est-ce que c’était fun… ↩

Ce mois-ci sur internals@php - Janvier 2013

Pascal MARTIN — Mon, 11 Feb 2013 07:00:00 +0100

Ce premier mois de l’année 2013¹ a été plutôt agité sur internals@, avec 1082 mails — la barre des 1000 mails sur le mois ayant été pour les deux dernières fois franchie en avril 2012 et en juin 2011 ; pas tous les jours, donc.
Sous forme d’un graphique représentant le nombre de mails par mois sur les trois dernières années, on obtient (l’historique depuis 1998 est disponible ici) :

Pour résumer de façon très rapide les quelques points principaux :

L’idée d’intégrer le cache d’opcodes Zend Optimizer+ à PHP 5.5 est en cours de discussion,
PHP 5.5 approche de la fin de versions alpha, et pourrait passer en phase de bêta (qui marque la fin de l’ajout/modification de fonctionnalités) début février,
PHP 5.3 devrait recevoir des correctifs de sécurité pendant un an après la sortie de PHP 5.5 ; après quoi, cette version aura atteint sa fin de vie,
La RFC sur les accesseurs n’est pas passée,
Le sujet des annotations est revenu sur le devant de la scène en début de mois ; avant de s’essoufler.

PHP 5.5 approche la bêta ; PHP 5.3 voit sa fin de vie à l’horizon

Pour ce qui est de PHP 5.5, la version alpha3 est sortie le 10 janvier ; et elle a été suivie, deux semaines après, par la version alpha4, publiée le 24 janvier.

En parallèle à la sortie de la 4ème version alpha, David Soria Parra a annoncé que l’alpha4 devrait être la dernière version alpha, et que la prochaine version de ce qui est en train de devenir PHP 5.5 devrait être la beta1, prévue pour le 7 février².

Comme je l’annonçais le mois dernier, le passage en phase de versions bêta marque la fin de l’ajout/modification de fonctionnalités (“feature-freeze”) ; d’ici peu, nous devrions donc être fixés sur l’ensemble des nouveautés qu’apportera PHP 5.5 !

En parallèle, le sujet de la probable prochaine EOL de PHP 5.3 a été relancé par Pierre Joye, qui annonce quelques jours plus tard l’ouverture du vote sur la RFC: Define PHP 5.3 end of life.

Et tout juste en fin de mois, les résultats du vote sont connus : une écrasante majorité (31 votes pour) de votants pense que PHP 5.3 devrait recevoir des correctifs de sécurité (uniquement) pendant un an, à partir de la sortie de PHP 5.5 ; en citant Pierre Joye :

That means PHP 5.3 end of life (no release, no support, etc.) will happen exactly one year after the release of PHP 5.5.0-stable.
The announce of the exact date will be done at the same time than the release announce for PHP 5.5.0.

Autrement dit³ :

Cela signifie que la fin de vie de PHP 5.3 (plus de sortie de version, plus de support, …) aura lieu exactement un an après la publication de PHP 5.5.0-stable.
L’annonce de la date exactement sera faite en même temps que l’annonce de la publication de PHP 5.5.0.

De son côté, Stas Malyshev se demande avec quelle fréquence les mises à jour mineures de PHP (5.4, principalement, ici) devraient être publiée.

Intégration d’un cache d’opcodes au coeur de PHP ?

Intégrer un cache d’opcodes (de manière générale, l’idée tourne souvent autour d’APC) au coeur de PHP est une idée qui revient fréquemment (y compris sur internals@) ; je me souviens d’une conférence organisée par l’AFUP à Lyon en 2007 ou 2008, alors que PHP 5.3 et PHP 6 étaient encore tous deux en plein développement, où j’avais discuté de ce sujet avec un des conférenciers.

Et, presque immanquablement, dès l’annonce de l’approche de la feature-freeze de PHP 5.5, il est de nouveau fait mention de l’idée d’intégrer APC au core de PHP.

APC manque de développeurs, et n’est pas en avance lorsqu’il s’agit de supporter une nouvelle version de PHP

Cela dit, tout n’est pas rose au royaume de l’extension APC qui manque cruellement de développeurs. En citant Rasmus Lerdorf, qui essaye d’expliquer pourquoi aussi peu de développeurs travaillent sur APC :

It is probably the most complicated piece of the entire stack.
It is a an op_array juggler doing a complex dance on a tight rope backwards and blindfolded.
It is essentially multi-threaded in that there are multiple processes all reading and writing the same chunk of memory while dealing with a compiler that spits out context-sensitive op_arrays that were never designed to be cached and executed this way.

Autrement dit :

Il s’agit probablement de la portion la plus compliquée de l’ensemble de la pile.
C’est un jongleur d’op_array effectuant une dance complexe sur une fine cordre, en marche arrière, avec un bandeau sur les yeux.
Ce composant est principalement multi-threadé, puisqu’il gère plusieurs processus qui lisent et écrivent tous depuis le même bloc de mémoire, tout en travaillant avec un compilateur qui génère des listes d’opcodes dépendant du contexte qui n’ont jamais été conçues pour être cachées et exécutées de cette manière.

Cela dit, il est extrêment réaliste, puisque, quelques phrases plus loin, il n’hésite pas à affirmer :

The real issue here is robustness and lag time between a PHP release
and and solid APC release

Soit :

Le vrai problème est la robustesse et le délai entre la sortie d’une version de PHP
et la publication d’une version stable d’APC lui correspondant.

En plus de cela, on peut craindre que les choses n’aillent pas en s’améliorant du côté d’APC dans les prochains mois, puisque qu’il affirme aussi :

One thing I can guarantee is that if we add it to core in its current condition
it will delay 5.5 by 6+ months if not longer.

Ce qui donne à la traduction :

Une chose que je peux garantir est que si nous ajoutons APC au coeur dans son état actuel,
cela repoussera la sortie de PHP 5.5 de 6 mois, voire même plus.

Bien entendu je ne peux qu’acquiesser lorsque Julien Pauli suggère que plus de documentation pourrait aider ; mais si APC est aussi difficile à maintenir que son développeur principal le laisse entendre, j’ai peur que cela ne facilite que peu la prise en main par de nouveaux développeurs…

Cela dit, un peu plus loin dans la conversation, Zeev Suraski indique que le composant Optimizer+ de Zend fonctionne avec PHP 5.4 et 5.5, est gratuit depuis plusieurs années, et qu’il serait envisageable de l’open-sourcer pour qu’il soit intégré au core de PHP (même si, comme pour APC, une partie du code date un peu et n’est pas nécessairement parfaite), et Rasmus Lerdorf semble d’accord avec cette idée, le but premier étant d’apporter une solution de cache d’opcode intégrée à PHP (sous-entendu, quelque soit son origine, que ça vienne de Zend ou de la communauté au départ).

Bien sûr, comme le souligne Anthony Ferrara, il risque d’être difficile de mettre ceci en place (d’autant plus qu’une RFC implique théoriquement un délai minimal de deux semaines) avant la sortie de la version beta1 et le gel de fonctionnalités correspondant ; il serait peut-être alors nécessaire de rajouter une version alpha5, et de décaler la sortie de la beta1 en conséquence.

Intégrer Zend Optimizer+ à PHP ?

Suite aux échanges dont je parlais au-dessus, Zeev Suraski a annoncé en toute fin de mois qu’il avait rédigé une RFC proposant d’intégrer le cache d’opcodes Zend Optimizer+, aujourd’hui closed-source mais gratuit, dans PHP : RFC: Integrating Zend Optimizer+ into the PHP distribution — au passage, il serait rendu open-source par Zend (le processus est déjà en cours, il semblerait).

Les résultats de benchmarks publiés avec la RFC indiquent que Zend Optimizer+ s’en sort plutôt bien au niveau performances (notamment comparé à APC, il ne fait généralement pas “pire”, voire même est “meilleur”) ; et cette extension supporte déjà les nouveautés apportées par PHP 5.5, et a très tôt été disponible pour PHP 5.4 (contrairement au cache d’opcodes APC, qui est le plus “populaire”, et qui a mis fort longtemps avant d’être vraiment compatible avec PHP 5.4).

Quelques voix s’élèvent pour souligner que Zend Optimizer+ ne supporte pas ZTS (Zend Thread Safety — PHP en mode multi-threads), et que c’est un point qui pourrait être considéré comme bloquant ; mais il semblerait que le support de ZTS puisse être re-mis en place sans trop de difficulté — et, dans le contexte d’un serveur Web, ceci n’est problématique que pour les installations de PHP sous Windows, en mode non-FastCGI (la majorité des utilisations de PHP se faisant en mode multi-processus, et pas multi-threads).

Pour résumer brièvement ce que j’indiquais au-dessus pour ceux qui s’interrogent sur la possibilité d’intégrer APC plutôt que O+, en l’état actuel des choses et comme le souligne Rasmus Lerdorf, APC manque cruellement de mainteneurs (il semble y avoir plus de développeurs sur internals qui connaissent les sources de O+, qui n’est pour l’instant pas open-source, que de contributeurs à APC !), ce qui rend d’après lui cette idée non-viable.

Cela dit, quelques autres développeurs ayant travaillé sur APC par le passé ne semblent pas prendre d’un très bon oeil l’intégration d’un autre outil à PHP (surtout jusqu’à présent développé en closed-source, en dehors de php.net) — alors que cela fait des années que l’idée d’intégrer APC au core revient fréquemment sur le tapis.

Intégrer O+ à PHP 5.5 pourrait repousser la sortie de cette future version d’environ deux mois, notamment pour se donner le temps de stabiliser (tester / valider) l’ensemble ; nombreux sont ceux qui considérent qu’un délai supplémentaire de deux mois est acceptable, considérant le gain que représenterait un cache d’opcodes inclu dans le core ; d’autres, néanmoins, trouvent qu’il serait dommage de repousser la sortie de PHP 5.5 pour cela, alors qu’il existe des alternatives ; et enfin, certains ne sont pas contre un délai, mais notent fort justement que repousser une version de PHP pour ajouter une fonctionnalité doit être une exception bien cadrée, et ne pas devenir une habitude.

En réponse, David Soria Parra (co-release-manager pour PHP 5.5) indique qu’une possibilité serait de ne pas retarder la sortie de la première bêta de PHP 5.5, et d’intégrer O+ pour une version bêta ultérieure, même si “bêta” est censée signifier “feature-freeze” ; pour l’instant, cette proposition n’a pas été suivie de retour.

Notons que la discussion s’est étendue aux interactions entre O+ et d’autres extensions proches, en termes de fonctionnement, du coeur de PHP, comme Xdebug ou Zend Guard Decoder, afin de s’assurer que l’intégration de l’une ne constitue pas un problème pour les autres.

Arrivés en fin de mois, les choses en sont là : l’idée d’intégrer Zend Optimizer+ dans le core de PHP est lancée, la RFC est rédigée et les retours sont dans l’ensemble assez positifs, même si cela peut signifier qu’il faille éventuellement repousser la sortie de PHP 5.5 de deux mois. Nous verrons dans les prochaines semaines l’évolution que prendra cette proposition !

ZTS : Zend Thread Safety

Plus ou moins suite à la discussion autour de Zend Optimizer+, qui ne supporte pour l’instant pas ZTS (Zend Thread Safety), Zeev Suraski a demandé pourquoi est-ce que certains développeurs utilisent ZTS — autrement dit, pourquoi est-ce que certains utilisent PHP en mode multi-threads plutôt qu’en mode multi-processus.

Il s’agissait uniquement d’une discussion visant à déterminer l’utilité, aujourd’hui, de ZTS, et pas à arriver à une quelconque décision quant à son avenir — je ne fais donc ici que rapporter quelques éléments d’information :

Alexey Zakhlestin a fort justement fait remarquer que ZTS est un pré-requis pour des extensions comme pthreads, qui permet justement d’utiliser des threads depuis du code PHP ; il en va de même pour quelques autres extensions, comme la fonctionalité de sandbox de runkit.
Laruence a répondu que ZTS est important pour les utilisateurs ayant PHP tournant sous IIS ou Apache avec le MPM workers (alors que FastCGI est censé être plus rapide et plus robuste).
Pierre Joye aimerait bien supprimer tout ce qui est TSRM (Thread Safe Resource Management) et passer à du LTS (Thread Local Storage) ; mais il reste le problème de Windows, où se reposer sur un mode multi-processus est peu efficace. Il estime par ailleurs qu’arrêter de penser à la thread safety serait une grosse erreur
Johannes Schlüter a fait noter qu’un bug de multi-threading a été reporté quelque chose comme un an après la sortie de PHP 5.4, et que vu l’importance du bug en question, il semblerait que le multi-thread ne soit qu’assez peu testé.
Indépendamment du coeur de PHP en lui-même, certains composants ne sont pas TS — tout ce qui est locale, par exemple.
Johannes Schlüter a aussi fait remarquer — et c’est notamment gênant en hébergement mutualisé — qu’il suffit, avec l’implémentation ZTS actuelle, d’un script avec une stack overflow pour tuer un processus entier ; et donc, tous les threads qu’il héberge (tombant en cascade d’autres requêtes exécutées en parallèle). Pour lui, simplifier la base de code (sous-entendu : en supprimant ce qui est TSRM) serait bénéfique, même s’il est possible que supprimer le mode multi-threads puisse avoir un impact négatif sur les performances dans certains cas d’utilisation.
Bas van Beek a pour sa part apporté un point de vue que l’on rencontre rarement : il utilise PHP en embed dans des applications C/C++ fortement threadées — et donc, pour lui, ZTS est un élément important ; cela dit, Zeev Suraski a répondu qu’il est d’accord sur l’importance de ZTS dans ce type de cas, et que c’est dans le contexte d’un serveur web multi-threadé qu’il posait la question ; néamoins, prêter moins largement attention à ZTS au niveau de l’équipe de développement de PHP signifierait probablement, en cascade, moins d’efforts au niveau des extensions…

RFC et processus de vote

Suite aux votes sur plusieurs RFC et fonctionnalités controversées, Anthony Ferrara s’est posé la question suivante : lors du vote sur une RFC, sur quoi exactement le vote doit-il porter ? Sur l’idée même de la fonctionnalité proposée par la RFC ? Ou sur l’implémentation qui accompagne généralement celle-ci ?

Les réponses sont assez variées, prouvant que chacun interprête les choses à sa façon : Pierre Joye remarque que les votes ne portent que sur des RFC accompagnées de patches (et donc, d’une implémentation), alors que Zeev Suraski souligne qu’il n’est que rarement demandé de voter pour des modifications de code (hors nouvelles fonctionnalités) et que les concepts devraient être plus importants que leurs implémentations. Les deux points de vue ont trouvé echo, pour autant que je puisse en juger.

Dans les faits, aujourd’hui, voter “pour” une RFC signifie accepter que l’implémentation l’accompagnant soit mergée dans la base de code de PHP — et donc, cette implémentation a un poids fort dans la décision. Est-ce quelque chose qui pourrait changer à l’avenir, par exemple avec des RFC votées alors qu’elles n’en sont qu’à la phase d’idée non accompagnée d’une implémentation ?

Quelques jours plus tard, Zeev Suraski remet en question une partie du processus de votes ; en particulier, suite au vote sur la RFC des accesseurs, il note que les votes n’ont pas toujours de durée bien cadrée.

David Soria Parra, pour ne citer qu’un avis, est d’accord sur le principe proposé au-dessus : un vote devrait avoir une date de début et une date de fin clairement définies dès que celui-ci est ouvert.

Anthony Ferrara note que ceux qui ne participent pas à la discussion sur internals@ autour d’une RFC ne devraient pas être autorisés à voter sur ladite RFC — le but étant de tenir compte des avis de ceux qui ont prêté suffisament attention à la RFC pour prendre part aux échanges qui l’ont accompagnés.

Au cours de ces différents échanges, on peut noter que Zeev Suraski est réaliste sur “la communauté” vs “les développeurs” : il fait remarquer, fort justement, que l’immense majorité des utilisateurs de PHP est silencieuse : pour chaque personne inscrite à internals@, il existe un milier de développeurs qui ne suivent pas ce qu’il s’y passe, les discussions qui y ont lieu, et ne participent pas aux décisions qui impactent le langage.

D’ailleurs, Pierre Joye en remet une couche lors qu’il affirme :

I think many of us are purely and simply totally out of sync with our users.
I have no immediate solution but this is something we must solve, now.

Autrement dit, en français :

Je pense que beaucoup d’entre nous sont purement et simplement désynchronisés par rapport à nos utilisateurs.
Je n’ai pas de solution immédiate, mais c’est un problème que nous devons résoudre, maintenant.

Zeev Suraski insiste par la suite sur le fait que PHP est devenu aussi populaire comme langage de programmation “web” sans les fonctionnalités qui lui ont été ajoutées ces dernières années ni celles en cours de débat, et que nombre de développeurs sont tout à fait content sans — en fait, d’après lui, ils seraient même plus content sans ces nouveautés, qui rendent le langage plus complexe qu’il ne l’était à une époque. Et même sur internals@, il n’est pas le seul à être de cet avis.

Ryan McCue apporte le point de vue d’un développeur s’intéressant au développement de WordPress, ce à quoi Larry Garfield répond que ce problème de l’oeuf et de la poule n’est pas sans solution : un effort pour pousser à la migration vers une version plus récente de PHP, tel que le mouvement GoPHP5 d’il y a quelques années, peut être efficace.
Cela dit, si WordPress, en tant qu’application PHP très répandue, commençait dès maintenant à encourager à utiliser PHP 5.3/4 dans ses requirements, cela serait déjà une si bonne chose…

Grosses discussions — sans résultat immédiat — sur les accesseurs, et sur les anotations

Deux séries de discussions et d’échanges, allant jusqu’à la rédaction de RFCs (et même jusqu’à la phase de vote pour certaines d’entre elles), ont eu lieu ce mois-ci, sans qu’aucune nouvelle fonctionnalité ne soit finalement ajoutée à PHP.

Ajouter une fonctionnalité d’accesseurs à PHP ?

Les multiples discussions sur les accesseurs sont sans aucun doute un des gros sujets de ce mois-ci sur internals@ :

Clint Priest travaille depuis plusieurs mois sur la mise en place d’accesseurs de propriétés ; il a annoncé en début de mois que la RFC: Property Accessors Syntax était sur le point d’être soumise aux votes, et demandait donc une relecture finale. Avec plus de 50 mails dans la discussion, c’est un sujet qui a semblé intéresser du monde !

Dans la suite logique des discussions évoquées au-dessus ainsi que de celles de ces derniers mois, Clint Priest a ouvert les votes sur sa proposition tout juste milieu janvier ; il était prévu, si la RFC passait, que cette fonctionnalité soit ajoutée à PHP 5.5.

Dans le fil de discussion, un avis de Rasmus Lerdorf — je ne cite qu’un intervenant et un mail, mais c’est loin d’être le seul qui aurait de quoi être attirer l’attention :

The simple explanation from me is that the ROI isn’t there on this one.
It adds a lot of code complexity for very little return. Yes, it saves a couple of lines of boilerplate code for a few people, but the cost is high in terms of ongoing maintenance and potential issues for opcode caches as well.
If you look at the split in voting you will notice it is pretty much split along the lines of the people who have to maintain this code vs. the people who would like a shiny new feature.

Soit, en français :

L’explication simple pour moi est que le retour sur investissement n’est pas intéressant pour ce point.
Il entraine l’ajout de beaucoup de complexité au code, pour un gain faible en échange. Oui, cela économise quelques lignes de code pour quelques personnes, mais le coût est élevé en termes de maintenance et de problèmes potentiels pour les caches d’opcodes.
Si on jette un coup d’oeil au partage des votes, on remarquera que la séparation se fait à peu près entre les gens qui auraient à maintenir ce code d’une part, et ceux qui voudraient une nouvelle fonctionnalité d’autre part.

(Les choses ne sont pas nécessairement aussi noires ou blanches, mais je trouve intéressante la distinction faite par le créateur du langage entre “les gens qui maintiennent le code” — les développeurs de PHP — et “les gens qui voudraient une nouvelle fonctionnalité” — les utilisateurs de PHP)

En parallèle, Nikita Popov a proposé une syntaxe alternative, et a rédigé la RFC: Alternative typehinting syntax for accessors ; cette proposition semblait rencontrer des avis plutôt positifs, et elle a donc été elle aussi ouverte aux votes — il est intéressant de noter (je crois que c’est la première fois que je vois le cas se produire) que cette RFC concerne un changement non pas sur une fonctionnalité existante de PHP, mais sur une fonctionnalité en cours de vote (et donc, si cette RFC passe, il faudra pour qu’elle soit appliquée que la première passe elle-aussi).

Dans le fil des échanges, on arrive tout de même à de jolies perles, comme, par exemple :

I’m against Accessors as well so if it goes through then I’ll definitely be stopping with PHP5.4
and ensuring that remains available for the rest of my active programming life …
something I wish I’d done now with 5.2!

Soit, après traduction :

Je suis moi aussi opposé aux Accesseurs donc si cette fonctionnalité passe, je m’arrêterai clairement à PHP 5.4
et m’assurerai que cette version reste disponible pour le restant de ma vie de développement actif…
quelque chose que je regrette finalement de ne pas avoir fait avec PHP 5.2 !

Et alors même que les deux RFC pointées plus haut étaient en phase de vote (les “oui” ne devancent que de peu les “non” sur la première, alors que pour passer, il faudrait 2/3 de “oui”), Steve Clay a lancé un nouveau sujet de discussion, où il a essayé d’introduire une nouvelle propostion, qui pourrait être perçue comme plus simple — ce à quoi Clint Priest n’a pu que répondre que, finalement, une des versions précédentes de sa RFC correspondait à peu près à cette nouvelle idée ; et que nombreux ont été ceux à demander les fonctionnalités ajoutées depuis…

Alors que la phase de votes touchait à sa fin, il a semblé que Clint Priest et Nikita Popov abandonnaient, considérant que leurs propositions avaient reçu beaucoup de votes “non” (dans les faits, plus de 20 votes “contre” et plus de 30 votes “pour” ; ce qui est insuffisant, puisqu’une modification du langage demande deux tiers de “pour” pour être acceptée) ; et ce fut confirmé quelques jours plus tard, avec 34 “pour” et 22 “contre”.

Donc, après plusieurs mois d’échanges : pour l’instant, la fonctionnalité d’accesseurs ne sera pas ajoutée à PHP 5.5 — ni à aucune version, tant qu’elle n’aura pas été revue de manière à arriver à un concensus.

Le retour des discussions sur les annotations

Yahav Gindi Bar a relancé le sujet des annotations, en proposant la RFC: Reflection Annotations using the Doc-Comment.

En soit, l’idée des annotations semble appréciée par pas mal de monde (elles sont utilisées par plusieurs “gros” frameworks genre Doctrine / symfony / Zend Framework) ; par contre, la proposition faite ici utilise une syntaxe qui n’est pas compatible avec celle utilisée “ailleurs”.

Comme l’a fait remarquer Pierrick Charron, ce n’est pas tout à fait la première fois que le sujet est abordé : il existe même déjà une première RFC : Annotations in DocBlock ; Clint Priest a aussi pointé vers RFC: Class Metadata, qui avait été proposée en 2010 par Guilherme Blanco… et qui n’était pas passée.

Mais, encore une fois, l’opposition est vocale ; par exemple, Derick Rethans avance que chaque application/framework utilisant ses propres conventions, un parser d’annotations n’a pas sa place dans le core de PHP.
Cependant, ici aussi, d’autres soutiennent qu’utiliser des DocBlocks pour travailler avec des annotations est un hack, et que cette fonctionnalité aurait sa place dans le core.

Enfin, bref ; j’ai l’impression de voir l’histoire se répéter (les échanges se sont étalés sur une grosse centaine de mails, répartis sur trois sujets de discussion principaux), avec d’un côté “les annotations c’est bien, ça devrait être dans le core de PHP”, et de l’autre “les annotations n’ont rien à faire dans le code de PHP”, avec, au milieu de tout ça, quelques remarques sur la séparation documentation/comportement, des interrogations à propos des caches d’opcodes, et des exemples volontairement exagérés pour être illisibles.

Il y a plus de deux ans, en 2010, le camp du “contre” avait remporté une bataille… Cette fois-ci, la discussion s’est essouflée d’elle-même au bout de quelques jours… Mais qui sait, les annotations ne sont pas le premier sujet à revenir régulièrement sur internals@, le sujet avance un petit peu à chaque fois, et peut-être qu’un jour…

De nombreux petits changements et améliorations

Je ne pense pas qu’il soit nécessaire d’écrire des paragraphes entiers à ce sujet, mais puisque cela a fait un peu de bruit : suite aux échanges, parfois houleux, qui ont eu lieu début janvier autour du sujet des annotations, Anthony Ferrara estime que “PHP a besoin d’une vision” : plutôt que de laisser chacun partir dans son coin, développer une fonctionnalité et rédiger la RFC correspondante et les soumettre à un vote, d’après lui, PHP aurait besoin d’une ligne de conduite générale.

Forcément, les avis en réponses divergent en fonction de chacun ; d’aucun sont satisfait du mode de fonctionnement actuel, d’autres préféreraient que PHP reste “simple”, et les derniers voudraient quasiment que toute fonctionnalité imaginée et imaginable soit ajoutée à PHP.

Finalement, il n’est pas ressorti grand chose des échanges qui ont suivi ; la discussion s’est essouflée ; et, tout au moins à court terme, aucun changement n’est visible quant aux processus d’ajout de fonctionnalité à PHP.

Le vote sur la RFC array_column() a enfin été ouvert.

Au départ deux noms de fonctions (array_column() et array_pluck()) étaient proposés ; finalement, seul le premier a été retenu — bien entendu le plus gros de la discussion a porté sur le nom à donner à cette fonction, et non pas sur la fonctionnalité en elle-même.

Avec 29 votes “pour”, et 6 votes “contre”, il semblerait que cette fonction ait de bonnes chances d’être présente dans PHP 5.5 — reste à ce que le code correspondant soit mergé avant le gel des fonctionnalités prévu pour dans quelques jours !

Le vote sur la RFC: Remove calls with incompatible Context, qui avait été rédigée cet été, a été ouvert par Gustavo Lopes en milieu de mois.

Une semaine après, la RFC est passée à l’unanimité (15 votes “pour”, et 0 vote “contre”) ; et le changement devrait être effectif pour PHP 5.5 — notons que malgré le nom de la RFC, il s’agit uniquement, pour PHP 5.5, d’un marquage comme deprecated.

Stas Malyshev a proposé une solution pour sécuriser l’upload de fichier avec ext/cURL, et a rédigé la RFC correspondante : RFC: Fix CURL file uploads.

Pour ceux qui voudraient plus d’explications sur la problématique de sécurité, ce mail de Stas Malyshev peut être une lecture intéressante.

Les votes ont été ouverts le 21 janvier, et devraient donc s’achever dans quelques jours. Les résultats étant plutôt positifs pour l’instant, il y a de fortes chances que la classe CURLFile soit présente dans la prochaine version de PHP.

Suite à une discussion sur reddit autour du Bug #52424, Damian Tylczyński a remis sur le tapis le sujet de l’inconsistence des noms de fonctions fournies par PHP.

C’est un débat qui revient fréquemment (ce n’est pas le seul — et des fois, au bout de plusieurs années, les choses changent ; ça a par exemple été le cas il y a quelques mois pour la déprécation de ext/mysql) sur la mailing-list internals@, entre ceux qui voudraient uniformiser les noms de fonctions (et, des fois, les ordres de paramètres, aussi), et ceux qui rappellent que la compatibilité avec les versions précédentes est une règle importante de PHP.

D’ailleurs, comme le souligne Stas Malyshev, pour ceux d’entre nous qui travaillent avec des bases de code existantes de grande taille, cette uniformisation n’apporterait absolument rien — sinon la nécessité de retoucher et retester des centaines de milliers de lignes de code.

Quelques modifications visant à améliorer les performances de PHP ont été effectuées :

Autour des manipulation de dates,
Pour la fonction strtr() ; certains ont exprimé le souhait que ceci soit mergé sur les branches de PHP 5.4 et de PHP 5.5 ; alors que d’autres répondaient qu’il y avait un risque de régression, et qu’il valait mieux garder ce type de nouveauté pour 5.5. Finalement ce point a été mergé sur PHP 5.4.
Quelques optimisation pour ARM.

Et, pour finir, voici encore quelques points intéressant, même si je n’estime pas utile d’en parler plus en profondeur :

En début de mois, Gustavo Lopes a annoncé l’ouverture des votes pour la RFC: zend_parse_parameters() improvements ; deux semaines après, avec 9 votes “pour” et 0 vote “contre”, la modification a été mergée vers PHP 5.5.
Il a aussi annoncé la RFC: send/recvmsg() wrappers in ext/socket ; c’est le genre de cas pour lequel une RFC ne serait à mes yeux pas nécessaire (ajout à une extension PHP d’une fonction présente dans la bibliothèque encapsulée par cette extension), mais il est appréciable de voir le principe des RFC appliqué de manière sérieuse ; quoi qu’il en soit, puisqu’aucun retour (ni positif, ni négatif) n’a été fait, ceci devrait être mergé sur la branche de PHP 5.5 dans les prochains jours.
ALeX Kazik a parlé d’un patch qu’il a écrit pour permettre de spécifier le répertoire temporaire depuis php.ini ; cet modification semble appréciée, et il y a de bonnes chances pour qu’elle soit appliquée prochainement, ajoutant une nouvelle directive nommée sys_temp_dir.
“PHP 6” commence à être évoqué pour de futures modifications ;-)
Stas Malyshev a proposé un correctif pour Bug #63462: Magic methods called twice for unset protected properties
Et pour fini, Nikita Nefedov a lancé une discussion sur une éventuelle intégration des symboles de Ruby ; qui n’a pas rencontré suffisament d’intérêt pour aller plus loin.

Cet article n’est pas tout à fait en avance — mais une semaine de retard ne devrait pas changer grand chose à son contenu. ↩
Finalement, il semblerait que la beta1 de PHP 5.5 n’ait pas été publiée le 7 février comme cela avait initialement été prévu ; je n’ai pas l’impression que cela ait été officiellement annoncé, mais j’imagine que c’est lié aux discussion en cours autour de l’éventuelle intégration de Zend Optimizer+ à PHP, qui pourrait décaler le planning de sortie de PHP 5.5. ↩
Les traductions fournies dans cet article sont toutes de moi et peuvent être un peu imprécises ; les citations réelles sont bien entendu les versions en anglais.
Je me suis aussi plusieurs fois accordé la liberté de graisser quelques passages qui me semblaient le mériter. ↩

Statistiques de versions de PHP - janvier 2013

Pascal MARTIN — Mon, 14 Jan 2013 07:00:00 +0100

Quelques cinq mois après le dernier article de cette série, publié en août 2012, voici un nouvel état des lieux des différentes versions de PHP et de leur utilisation sur Internet — à titre de comparaison, vous voudrez peut-être aussi jeter un coup d’œil à l’article que j’avais publié il y a un an, en janvier 2012.

Les données présentées dans cet article ont été collectées le week-end du 12 janvier 2013. Les versions stables de PHP sont PHP 5.3.20 et PHP 5.4.10 qui ont été publiées le 20 décembre 2012 ; cela fait tout juste deux ans que PHP 5.2 n’est plus supportée ; et la 3ème version alpha de PHP 5.5 a été publiée il y a quelques jours.

Sommaire :

Quelques mots sur la méthode

Pour faire simple¹, j’ai récupéré une liste de plus de 9.4 millions de noms de domaines, issus principalement :

Du top 1 million d’Alexa (chargé plusieurs fois à quelques semaines/mois d’écart sur l’année et demie écoulée, ce qui donne maintenant nettement plus de 1 million de noms de domaines),
Des liens externes de wikipedia de plusieurs langues (environ 3 millions de noms de domaines),
De l’export mis à disposition par l’Export Open Directory (environ 2 millions de noms de domaines, certains correspondant à des sites un peu anciens et pas vraiment mis à jour),
Et de quelques résultats de recherche google (quelques milliers de noms de domaines).

Ensuite, pour chacun de ces noms de domaines, j’ai effectué une requête HTTP HEAD sur domaine.tld, en me rabattant sur www.domaine.tld si la première requête échouait.

Après cela, je me suis généralement² basé sur l’en-tête HTTP X-Powered-By renvoyée par le serveur, pour en extraire le nom de logiciel ayant servir à générer la page, ainsi que sa version.
Et dans le cas où cette en-tête n’existe pas, ou ne contient pas d’information exploitable, je me suis rabattu sur l’en-tête Server.

Pour rappel, et en ne prenant que quelques exemples relativement typiques, les en-têtes HTTP renvoyées par le serveur, dans le cas de pages générées par PHP et sur un serveur exposant la version de PHP utilisée, ressemblent souvent à quelque chose de ce type (pour www.php.net) :

Server: Apache/2.2.21 (FreeBSD) mod_ssl/2.2.21 OpenSSL/0.9.8q PHP/5.4.11-dev
X-Powered-By: PHP/5.4.11-dev

ou (pour drupal.org) :

Server: Apache/2.2.3 (CentOS)
X-Powered-By: PHP/5.3.16

A partir de là, extraire le numéro de la version de PHP utilisée est une opération relativement aisée…

Quelques chiffres

Réponses PHP

Sur les 8.7 millions de requêtes HTTP effectuées sur les noms de domaines que j’ai testé, environ 26% des réponses ont été identifiées comme générées par du PHP.

Plus précisément, j’ai identifié 2,228,529 réponses comme correspondant à du PHP.

Avec ce nombre relativement conséquent de réponses, les statistiques présentées plus bas devraient avoir des chances d’être à peu près correctes, ou, tout au moins, de donner des résultats et chiffres relativement proches de la réalité…

Serveurs Web

Cela dit, avant d’entrer dans les détails des versions de PHP, voici la liste des Serveurs Web les plus fréquemment identifiés lors de ma collecte de données :

Apache : 5,164,189 — 66.07%
IIS : 1,377,796 — 17.63%
nginx : 554,345 — 7.09%
Autres : 367,593 — 4.70%
GSE : 190,096 — 2.43%
LiteSpeed : 63,995 — 0.82%
YTS : 55,838 — 0.71%
Oversee Turing v1.0.0 : 42,196 — 0.54%

Ou, sous forme d’un graphe :

On ne constate pas de véritable révolution par rapport aux données collectées il y a cinq mois ou il y a un an :

Apache, toutes versions confondues, reste encore très loin devant tous les autres, servant deux tiers des pages interrogées — mais perd quelque chose comme 1.7 point en un an,
IIS conserve sa seconde place — en perdant 1 point en un an,
Et nginx est encore en troisième place — en ayant gagné plus de 1.5 point en un an.

Versions majeures de PHP

Commençons par les versions majeures de PHP, en prenant en compte les résultats qui ont été identifiés comme correspondant à une version supérieure ou égale à 3, et inférieure ou égale à 6³.

Mes tests ont remonté le nombre suivant de domaines sur chaque version majeure de PHP :

PHP 3 : 648 — 0.03%
PHP 4 : 191,521 — 8.59%
PHP 5 : 2,036,247 — 91.38%
PHP 6 : 17 — 0.00%

Sous forme d’un graphe, qui peut être plus parlant pour certains et permet de voir en un clin d’œil quelle est la version majeure de PHP la plus répandue, cela donne :

On notera :

Que, fort heureusement, PHP 5 est la version majeure la plus répandue ; PHP 5 passe d’ailleurs pour la première fois au-dessus des 90%,
Mais que, début 2013, on a encore quelques centaines de sites, sur 8.7 millions, qui tournent encore sur du PHP 3,
Et aussi que PHP 4 est encore vraiment trop répandue, alors que cela fait des années que cette version n’est plus du tout maintenue (PHP 4.4.9, publiée en Août 2008, était annoncée comme étant la dernière version de PHP 4.x),
Et enfin que, bientôt trois ans après la mise à mort de la branche PHP 6 (qui, pour rappel, n’a jamais vu une version ne serait-ce qu’alpha être publiée), on rencontre (encore) des sites qui utilisent PHP 6 en production ???

Versions mineures de PHP

Si on passe aux versions mineures de PHP, toujours pour PHP >= 3.x et PHP <= 6.x, et en ne conservant que les versions qui sont remontées 10 fois ou plus, on obtient les données suivantes :

PHP 3.0 : 646 — 0.03%
PHP 4.0 : 1,469 — 0.07%
PHP 4.1 : 3,434 — 0.15%
PHP 4.2 : 3,133 — 0.14%
PHP 4.3 : 40,804 — 1.83%
PHP 4.4 : 142,681 — 6.40%
PHP 5.0 : 5,085 — 0.23%
PHP 5.1 : 69,958 — 3.14%
PHP 5.2 : 1,014,151 — 45.51%
PHP 5.3 : 910,630 — 40.86%
PHP 5.4 : 36,410 — 1.63%
PHP 6.0 : 17 — 0.00%

Et sous forme graphique :

Pour résumer :

PHP 5.2, qui a atteint sa fin de vie en décembre 2010, il y a deux ans, est encore la version de PHP qui semble aujourd’hui la plus utilisée / répandue — mais les choses vont dans le bon sens, puisque PHP 5.2 est pour la première fois passée sous la barre des 50% ! (51.42% en août 2012, et 62.35% en janvier 2012)
PHP 5.3, stable depuis juin 2009, soit trois ans et demi, n’arrive toujours qu’en seconde place — mais continue à se rapprocher de la première, et va probablement bientôt l’atteindre,
PHP 5.4, dont la première version stable a été publiée le 1er mars 2012, monte tout doucement en puissance, puisqu’elle ne représente que 1.63% des installations comptabilisées.
Pour la petite histoire : cela ne se voit pas ici, mais j’ai identifié 8 serveurs en PHP 5.5.0 (un en -alpha1, un en -alpha3, et les autres en -dev)

On peut donc dire que PHP 5.3 s’est enfin imposée !

Pas trop tôt devrais-je dire, puisqu’il est fort probable que PHP 5.3 atteigne bientôt sa fin de vie — peut-être au moment de la sortie de PHP 5.5, qui pourrait avoir lieu au printemps… Autrement dit, si, en 2013, vous êtes encore avec une version <= 5.2, il n’est plus temps de passer à PHP 5.3, mais bel et bien à 5.4 ;-)

Et il peut aussi être temps de commencer à vous pencher sur PHP 5.5, qui propose plein de nouveautés intéressantes, et est actuellement en phase de versions alpha.

Versions releases de PHP

Et enfin, si on descend au niveau des versions release de PHP 5.x⁴, en ne conservant que les versions qui remontées 100 fois ou plus, on obtient les données suivantes :

Pour PHP 5.0 :
- 5.0.1 : 107 — 0.01%
- 5.0.2 : 236 — 0.01%
- 5.0.3 : 527 — 0.03%
- 5.0.4 : 3,428 — 0.17%
- 5.0.5 : 763 — 0.04%
Pour PHP 5.1 :
- 5.1.1 : 265 — 0.01%
- 5.1.2 : 4,486 — 0.22%
- 5.1.3 : 1,601 — 0.08%
- 5.1.4 : 1,785 — 0.09%
- 5.1.5 : 204 — 0.01%
- 5.1.6 : 61,603 — 3.03%
Pour PHP 5.2 :
- 5.2.0 : 16,866 — 0.83%
- 5.2.1 : 4,587 — 0.23%
- 5.2.2 : 1,313 — 0.06%
- 5.2.3 : 5,774 — 0.28%
- 5.2.4 : 34,101 — 1.67%
- 5.2.5 : 25,145 — 1.23%
- 5.2.6 : 124,980 — 6.14%
- 5.2.7 : 184 — 0.01%
- 5.2.8 : 17,303 — 0.85%
- 5.2.9 : 54,962 — 2.70%
- 5.2.10 : 33,994 — 1.67%
- 5.2.11 : 21,099 — 1.04%
- 5.2.12 : 28,176 — 1.38%
- 5.2.13 : 31,587 — 1.55%
- 5.2.14 : 36,442 — 1.79%
- 5.2.15 : 3,137 — 0.15%
- 5.2.16 : 11,545 — 0.57%
- 5.2.17 : 562,822 — 27.64%
- 5.2.18⁵ : 113 — 0.01%
Pour PHP 5.3 :
- 5.3.0 : 2,522 — 0.12%
- 5.3.1 : 3,310 — 0.16%
- 5.3.2 : 52,101 — 2.56%
- 5.3.3 : 208,429 — 10.24%
- 5.3.4 : 3,574 — 0.18%
- 5.3.5 : 24,212 — 1.19%
- 5.3.6 : 78,797 — 3.87%
- 5.3.7 : 590 — 0.03%
- 5.3.8 : 57,818 — 2.84%
- 5.3.9 : 8,071 — 0.40%
- 5.3.10 : 89,158 — 4.38%
- 5.3.11 : 904 — 0.04%
- 5.3.12 : 552 — 0.03%
- 5.3.13 : 33,792 — 1.66%
- 5.3.14 : 21,402 — 1.05%
- 5.3.15 : 50,011 — 2.46%
- 5.3.16 : 32,741 — 1.61%
- 5.3.17 : 34,282 — 1.68%
- 5.3.18 : 115,808 — 5.69%
- 5.3.19 : 56,717 — 2.79%
- 5.3.20 : 35,831 — 1.76%
Pour PHP 5.4 :
- 5.4.0 : 983 — 0.05%
- 5.4.1 : 140 — 0.01%
- 5.4.3 : 1,452 — 0.07%
- 5.4.4 : 4,115 — 0.20%
- 5.4.5 : 1,413 — 0.07%
- 5.4.6 : 3,749 — 0.18%
- 5.4.7 : 3,832 — 0.19%
- 5.4.8 : 3,340 — 0.16%
- 5.4.9 : 5,914 — 0.29%
- 5.4.10 : 11,384 — 0.56%

Et sous forme graphique :

Pour résumer :

Toujours une quantité non-négligeable (3.03%) de sites sous PHP 5.1.6 (qui a été publiée en Août 2006) ; la version fournie par défaut sous certaines distributions, il me semble, genre Redhat Enterprise.
Beaucoup de PHP 5.2.6 (6.14%) (publiée en Mai 2008) ; la version fournie par défaut sous Debian Lenny, par exemple.
La version de PHP la plus répandue est PHP 5.2.17 (publiée en Janvier 2011), avec 27.64% ; ça reste du 5.2, qui a atteint sa fin de vie, mais positivons, en se disant que c’est la dernière version, la plus à jour…
Et enfin, plusieurs sous versions de PHP 5.3.x, sans qu’aucune ne s’impose vraiment ; entre autres :
- PHP 5.3.3, qui est la version 5.3.x la plus représentée avec 10.24% — la version par défaut sous Debian Squeeze, notamment,
- PHP 5.3.10 (4.38%) — version par défaut sous Ubuntu 12.04 (qui est une LTS — dommage, les 6 versions de retard), par exemple.

Pour PHP 5.3 et 5.4, hormis les versions fournies par quelques grandes distributions, on constate qu’aucune version ne s’impose réellement, et que toutes se partagent une petite part des serveurs installés ; si je devais me risquer à une interprétation, je dirais que les hébergeurs ont du mal à suivre le rythme de publication des mises à jour, qui tourne depuis quelques temps à une nouvelle version par mois (l’idée étant, bien entendu, de publier plus rapidement les corrections de bugs).

Evolution

Je ne ferai pas une longue analyse sur le pourquoi du comment des chiffres que j’ai présenté ici : libre à vous de commenter sur le trop grand usage de versions complètement obsolètes, et le manque de mise à jour que l’on peut, malheureusement, trop souvent constater…

Cela dit, puisque ce n’est pas la première fois que j’effectue ce processus de collecte de statistiques à propos des versions de PHP utilisées, je me suis dit qu’il pouvait être intéressant de tracer un graphe représentant l’évolution de ces utilisations.

Le graphe reproduit ci-dessous présente donc l’évolution de l’utilisation des versions mineures de PHP, depuis septembre 2011⁶ :

J’ai essayé de mettre en évidence les versions les plus à même de nous concerner en ce moment (à savoir, PHP 5.2, 5.3, et 5.4), ainsi que, dans une moindre mesure les deux autres versions les plus utilisées (autrement dit, PHP 4.4 et 5.1).

Je disais dès avril 2012 que PHP 5.2 laissait petit à petit sa place à PHP 5.3, et en août 2012 que c’était encore plus visible quelques mois plus tard… Nous en sommes désormais au point où PHP 5.3 a quasiment rattrapé PHP 5.2⁷ !

Maintenant, à nous de faire en sorte que PHP 5.4 soit adopté plus rapidement que PHP 5.3 ne l’a été — PHP 5.3 semblant être sur le point d’atteindre sa fin de vie, et la migration 5.3 -> 5.4 représentant un pas moins important que celui séparant PHP 5.2 de 5.3.

Oui, il y a beaucoup de copier-coller d’article en article, pour cette section “méthode” : elle ne change pas d’une fois à l’autre. ↩
Pour certains types de serveurs ou de logiciels, j’ai mis en place un bout de code qui va chercher les informations de version dans d’autres en-têtes que X-Powered-By. Par exemple, pour les sites développés en ASP.NET, les informations de version figurent généralement dans une en-tête nommée X-AspNet-Version. ↩
Pour ne pas prendre en compte les quelques résultats abherrant qu’on aurait pu relever. ↩
PHP 4 correspondant à des versions tellement dépassées que je préfére ne pas prendre la peine de rentrer au niveau des versions release. ↩
Oui, j’ai trouvé des serveurs indiquant qu’ils utilisaient une version 5.2.18 de PHP — alors qu’il n’existe pas “officiellement” de version 5.2.18.
En pratique, la version indiquée est généralement PHP/5.2.18-dev (sur snowfactory.fi par exemple ; ce suffixe -dev correspond typiquement à un build depuis les sources de la branche 5.2 de PHP), ou PHP/5.2.18-edong (sur damophoto.com par exemple ; pour ce suffixe -edong, aucune idée de son origine ; je ne me rappelle pas l’avoir vu auparavant — possiblement un hébergeur qui fait ses propres build de PHP ?) ↩
Les chiffres présentés sur le graphique d’évolution sont en pourcentages, afin d’être indépendants du nombre d’hôtes interrogés, qui varie à chaque série de collectes. ↩
J’ai bon espoir de pouvoir annoncer, la prochaine fois où je publierai un article de cette série, que PHP 5.3 aura dépassé PHP 5.2, et sera alors en première place ;-) ↩

PHP 5.2 n'est plus supportée depuis deux ans !

Pascal MARTIN — Mon, 07 Jan 2013 07:00:00 +0100

PHP 5.2.16, publiée il y a plus de deux ans, le 16 décembre 2010, était censée être la dernière version de la branche 5.2 (je cite) :

This release marks the end of support for PHP 5.2.
All users of PHP 5.2 are encouraged to upgrade to PHP 5.3.

Et en français :

Cette version marque la fin du support pour PHP 5.2.
Tous les utilisateurs de PHP 5.2 sont encouragés à mettre à jour vers PHP 5.3.

Pour éviter de rester avec un bug critique, elle a été suivie quelques jours après, le 6 janvier 2011, d’une version 5.2.17 — qui a effectivement marqué la fin des développements pour la branche 5.2 de PHP, puisqu’aucune autre version n’a été publiée dans les deux années qui ont suivies.

Autrement dit, cela fait aujourd’hui deux ans que PHP 5.2 n’est plus supportée : plus la moindre évolution, ce qui est une chose, mais plus non plus de correction de bug, ni même de correction d’éventuelles failles de sécurité !

Donc, si vous êtes encore bloqué à PHP 5.2 (ou même à une version inférieure) deux ans après la fin de son support¹, une bonne résolution pour cette année qui commence pourrait être de monter de version de PHP ;-)
Par exemple, pour passer à PHP 5.4, dont la première version stable a été publiée il y a dix mois, le 1er mars 2012.

Vous noterez que je ne vous conseille pas de passer à PHP 5.3 : cette branche, dont la première version stable a été publiée le 30 juin 2009, va elle-même probablement bientôt atteindre sa fin de vie².

Quelques liens qui vous aideront peut-être à effectuer cette migration :

Vous pouvez aussi vouloir commencer à vous pencher sur PHP 5.5, actuellement en phase de versions alpha et qui pourrait être publiée en version stable au printemps, avec la série d’articles que j’ai rédigé sur PHP 5.5, et la page de manuel migration de PHP 5.4.x à PHP 5.5.x.

A titre d’information, vous pouvez vous reporter à la page unsupported branches, qui liste, pour chaque version de PHP, depuis quand elle n’est plus supportée.

Vous ne manquerez d’ailleurs pas de noter le passage suivant (je cite, emphasis mine) :

If you are using these releases, you are strongly urged to upgrade to a current version,
as using older versions may expose you to security vulnerabilities and bugs
that have been fixed in more recent versions of PHP.

Autrement dit :

Si vous utilisez une de ces versions, vous êtes fortement encouragé à mettre à jour vers une version actuelle,
car utiliser des versions plus anciennes peut vous exposer à des failles de sécurité et à des bugs
qui ont été corrigés dans des versions plus récentes de PHP.

Lorsque j’ai publié mes statistiques de versions de PHP en août 2012, PHP 5.2 représentait encore plus de la moitié des versions de PHP détectée !
(Je vais essayer de mettre à jour ces statistiques dans les prochaines semaines) ↩
Il y a des chances de l’EOL (End Of Life — Fin De Vie) de PHP 5.3 soit annoncée au moment de la sortie de PHP 5.5, pour éviter d’avoir trois versions de PHP à maintenir. ↩

Ce mois-ci sur internals@php - Décembre 2012

Pascal MARTIN — Tue, 01 Jan 2013 23:00:00 +0100

Pour commencer ce récapitulatif de ce qui m’a semblé être les principaux événements et sujets de discussions sur la mailing-list internals@ en ce mois de décembre 2012, David Soria Parra et Julien Pauli, Release Managers de PHP 5.5, annoncent un planning de sortie pour PHP 5.5.

Cela commence par une seconde alpha mi-décembre, un mois après la première, (cette version alpha2 a été publiée le 21 décembre)
Viendront probablement ensuite une alpha3 (qui aurait pu sortir fin décembre ; ça sera plutôt probablement pour début janvier) et peut-être une alpha4 (mi-janvier ?),
Qui seront suivies de probablement deux versions beta, la phase de beta marquant la fin de l’ajout/modification de fonctionnalités (“feature-freeze”).

Suite à cet enchainement de versions alpha et beta, on peut s’attendre à plusieurs versions RC — ce qui ménerait à une sortie de PHP 5.5.0 pour les environs d’avril 2013 (soit un peu plus d’un an après la sortie de PHP 5.4).

Plus ou moins en parallèle, Johannes Schlüter lance le sujet de la fin de vie de PHP 5.3, PHP 5.3.0 étant sortie en juin 2009, et PHP 5.4.0 ayant été publiée en mars 2012.

La difficulté majeure qui va se poser est la lenteur d’adoption de PHP 5.4 par les distributions Linux ; en particulier par les distributions orientées “entreprise” (RHEL 6.3 n’en n’est qu’à PHP 5.3.3), qui sont très longues à adopter de nouvelles versions, ou par les distributions “LTS”.

Le plus gros des problèmes posés par APC en combinaison avec PHP 5.4, qui ont longtemps empéché/retardé la migration d’un nombre non-négligeable de serveurs/applications devraient être réglés : au maximum, il doit rester des bugs déjà présents avec PHP 5.3 ; en citant Rasmus Lerdorf :

APC is at the point now for 5.4 where I don’t think there are any more
edge cases than we have in 5.3. Neither is perfect, but it is close
enough for the majority of sites.

Notons aussi que “EOL” ne veut pas dire que PHP 5.3 cessera de fonctionner ; et cette version continuera probablement à recevoir des correctifs pour les bugs critiques pendant quelques temps (un an ?).

Je n’ai pas le sentimentant qu’un concensus ait réellement été atteint ; cela dit, plusieurs développeurs souhaitent que PHP 5.3 soit annoncé comme atteignant son EOL lors de la sortie de PHP 5.5, pour ne pas avoir trois versions à maintenir en parallèle (PHP 5.3, PHP 5.4, et PHP 5.5) — et leur argument est somme toute rationnel : autant concentrer les efforts sur le développement de nouvelles fonctionnalités et d’améliorations pour les futures versions du langage, plutôt que de continuer à travailler éternellement sur des versions datant de plusieurs années.

Suite à la RFC et au vote dont je parlais le mois dernier, l’extension ext/mysql sera marquée comme dépréciée dès PHP 5.5.

Cela fait plusieurs années que ext/mysql n’est plus “la” solution qui devrait être utilisée pour interroger une base de données MySQL à partir de PHP, mais un rappel ne peut pas faire de mal ; n’hésitez donc pas à communiquer sur ce point : nous devrions tous utiliser ext/mysqli ou PDO.

Comme le fait remarquer Nikita Nefedov depuis son mail DateTime improvement, de nombreux développeurs ont tendance à traiter un objet DateTime comme étant variable (“mutable”, en anglais), ce qui, techniquement, est le cas ; alors qu’une date est, par nature, immuable (“immutable en anglais”)¹.

En l’état actuel des choses, une classe DateTimeImmutable a été implémentée, correspondant à une date immuable ; cette fonctionnalité n’a pas encore été mergée, et n’est pour l’instant disponible que sur la branche Git immutable-date².

Quelques mois après l’ajout des Generators à PHP 5.5, Nikita Popov propose de leur ajouter une méthode throw() — que l’on peut déjà trouver en Python ou en ECMAScript.

Cette proposition n’ayant pas rencontré d’opposition, elle a été commitée pour PHP 5.5.

Lars Strojny note que le PHP Core (les développeurs de PHP en lui-même) n’a pas une voix au sein du PHP FIG (Framework Interoperability Group), et que c’est quelque chose qu’il pourrait être intéressant de changer : Core liason for PHP FIG.

Dans les grandes lignes (en dehors des écarts sur le rôle du FIG, sur sa légitimité à représenter “tout le monde”, sur le fait qu’il ne constitue pas une autorité universellement reconnue, ou sur l’indentation à 2-4 espaces ou tabulations), le sentiment global est que le PHP Core n’a pas vraiment à influencer la manière dont les applications en PHP sont écrites (en particulier, pour les normes de codages, puisque PHP est écrit en C — alors que les applications PHP, elles, sont écrites, de toute évidence, en PHP).

En fait, comme le souligne Pierre Joye, il serait peut-être bon que l’inverse se produise, et que plus de développeurs travaillant sur les différentes applications et frameworks développés en PHP s’impliquent sur le développement de PHP en lui-même ; cela aiderait sans aucun doute à synchroniser les besoins des uns avec l’orientation que prend le langage PHP.

Pierrick Charron a lancé une discussion autour d’ext/curl, suite au changement de comportement de l’option CURLOPT_SSL_VERIFYHOST de libcurl (la bibliothèque que ext/curl expose à PHP) : la valeur 1 n’est plus disponible pour cette option.

En fonction de la version de libcurl utilisée par PHP, désormais, passer la valeur 1 pour l’option CURLOPT_SSL_VERIFYHOST entrainera la levée d’une notice, indiquant :

soit que valeur est obsolète, et ne sera bientôt plus supportée,
soit que cette valeur n’est plus supportée, et que 2 sera utilisée à la place.

Donc, potentiellement, il se peut que vous ayiez du code à corriger (et ce dès PHP 5.3) — en particulier si vous aviez considéré que cette option attendait un booléen.

Andrey Andreev propose que les fonctions de manipulation de cookies envoient l’attribut Max-Age dans l’en-tête HTTP Set-Cookie, pour spécifier la durée de vie du cookie, à partir de l’instant présent : Bug #23955: Cookie Max-Age attribute.

Quelques jours après, il a rédigé la RFC correspondante : RFC: Cookie Max-Age attribute.

Les quelques retours (encore peu nombreux, la RFC ayant été rédigée à la toute fin du mois) postés jusqu’à présent ont l’air plutôt positifs.

Victor Berchet propose que plus de structures de données soient implémentée dans PHP. La conversation s’est un peu essoufflée avec la fin d’année ; mais elle a tout de même eu le temps de s’orienter vers la Spl et des différentes classes que celle-ci propose ; classes qui, pour certaines, gagneraient à être retravaillées, d’ailleurs.

Yussuf Khalil propose d’ajouter un modificateur deprecated pour les fonctions et méthodes, et a rédigé la RFC correspondante : RFC: Add a deprecated modifier for functions.

L’idée est que les développeurs d’une bibliothèque ou d’un framework PHP puissent indiquer facilement (et que ce soit exporté via l’API de Reflection, comme c’est le cas pour les fonctions internes à PHP) qu’une fonction/méthode est obsolète, et sera retirée dans une prochaine version.

Dans l’ensemble, les retours sont plutôt opposés à cette proposition, considérant qu’il est difficile/risqué d’ajouter un nouveau modificateur, et qu’appeler trigger_error() au début d’une fonction en levant un avertissement de niveau E_DEPRECATED, tout en ajoutant un tag @deprecated à la phpdoc (pour les IDE notamment), n’est pas une opération complexe pour le développeur de la bibliothèque et permet d’indiquer un message plus précis (comportant par exemple un pointeur vers la solution à utiliser en remplacement).

Bien sûr, comme chaque mois, nous avons droit à quelques correctifs de bugs (par exemple, Bug #52752 : Crash when lexing), ainsi qu’à des améliorations orientées performances ; par exemple pour la fonction date(), ou avec le sujet execute_data->Ts removing.

En parallène, Dmitry Stogov a commencé à travailler sur une refonte de l’implémentation des Traits, l’implémentation courante n’étant pas optimale et se détériorant à chaque correctif, rendant plus difficile la mise en place des suivants. En fonction des retours, ces améliorations pourraient être commitées sur la branche PHP 5.4 dans les prochaines semaines.

Et pour finir sur une note qui serait presque comique (si ce n’était pas en même temps assez triste…), un post de Lester Caine qui note que les choses bougent lentement dans le monde réel ;).

En l’occurence, l’hébergeur 1&1 annonce la fin du support de PHP 4 et de PHP 5.2 pour le 1er avril 2013 — ce qui signifie, oui, qu’ils supportent encore PHP 4 !

Mais aussi, et c’est encore plus surprenant, leur FAQ annonce (je cite) :

To parse a script as PHP 5.4, simply name the script with the file extension .php6

Autrement dit :

Pour qu’un script soit interprété comme du PHP 5.4, il suffit de nommer le fichier avec l’extension .php6.

Arrivés fin 2012 / début 2013, considérant l’histoire de PHP 6, ça laisse songeur, n’est-ce pas ?

Pour plus d’informations sur les objets variables / immuables, vous pouvez consulter :
- Objet immuable en français,
- ou Immutable object en anglais,
- ou encore Java theory and practice: To mutate or not to mutate?.
↩
Comme le souligne Pierre Joye, il aurait été intéressant de respecter les processus mis en place, et de rédiger une RFC avant de commencer à implémenter cette nouvelle classe DateTimeImmuable sur le repository Git de PHP — même si elle s’est faite sur une branche séparée… ↩

Ce mois-ci sur internals@php - Novembre 2012

Pascal MARTIN — Mon, 03 Dec 2012 07:00:00 +0100

L’événement principal de ce mois de novembre 2012 sur la mailing-list internals@ est probablement l’annonce de la création de la branche 5.5 de PHP, ainsi que de la sortie de la première version alpha :

Branching PHP-5.5 : le 30 octobre, David Soria Parra annonce que la branche PHP 5.5 va être créée dans les jours qui suivent.
HEADS UP: PHP-5.5 branched : dans la suite de l’annonce précédente, David Soria Parra annonce le 13 novembre que la branche 5.5 a été créée.
PHP 5.5.0alpha1 Released for Testing! : et le 15 novembre, voici l’annonce de la sortie de la première version alpha de PHP 5.5.

Ces annonces marquent le début de la phase de release de PHP 5.5, qui va voir s’enchainer versions alpha, bêta, et RC, jusqu’à la sortie de la première version stable — peut-être au printemps ou au début de l’été prochain.

Vient ensuite ce qui a sans aucun doute été LA discussion de ce mois, avec 163 mails au moment où j’écris ceci : Adam Harvey annonce le 12 novembre qu’il a publié la RFC: ext/mysql deprecation.

Dans l’ensemble, les différents intervenants sont d’accord sur le principe que ext/mysql devrait être marquée comme obsolète un jour, et probablement sortie du core et déplacée vers PECL un jour. Cela dit, le gros de la question porte sur quand ce marquage en E_DEPRECATED devrait avoir lieu : pour PHP 5.5 ? ou plus tard ?

Depuis, les choses ont avancé d’une étape, puisque la RFC est en cours de vote depuis le 28 novembre : [VOTE] ext/mysql deprecation in 5.5 — ce fil de discussion en est à 40 mails au moment où j’écris ceci, ce qui fait un total de plus de 200 mails autour de ext/mysql en moins d’un mois !
En l’état actuel, à la question “est-ce que ext/mysql doit générer des erreurs E_DEPRECATED dès PHP 5.5”, 21 intervenants ont voté pour, et 12 contre.

Pour plus d’informations sur ce sujet, je vous encourage vivement à lire :

Sur ce blog, l’article Arrêtez d’utiliser les fonctions mysql_*() !, que j’ai publié il y a une dizaine de jours,
Et Supercharging PHP MySQL applications using the best API.

Clint Priest poursuit le travail de ces derniers mois autour de l’implémentation d’accesseurs de propriétés :

Request for Comments: Property accessors syntax - As Implemented : la RFC décrivant la proposition,
[RFC] Property Accessors v1.2 Consensus Changes : la suite de la discussion sur internals@ ; quoique moins active ce mois-ci.

Je disais dans l’article En route vers PHP 5.5 : Quelques backward-compatible breaks que les fonctions php_egg_logo_guid(), php_logo_guid(), et php_real_logo_guid() avaient été supprimées pour PHP 5.5¹.

Philip Olson s’en étonne, et demande Where did the logo functions go?.

Le coeur de la discussion, en fait, ne porte pas tant sur la suppression en soit de ces fonctions (elles n’étaient pas vraiment utiles, et pas tellement utilisées), mais sur le fait qu’elles aient été supprimées “par surprise”, sans qu’une RFC ne soit rédigée, ni qu’un avertissement E_DEPRECATED ne soit levé auparavant — en cela, le “processus” “standard” n’a pas vraiment été suivi…

Florin Razvan Patan a lancé une discussion autour d’une éventuelle implémentation d’une interface de logging au sein de PHP : Implement a LoggerInterface to PHP.

Une telle interface est un besoin récurrent de nombreuses applications, et une implémentation directement dans PHP apporterait de la cohérence entre frameworks, qui pourraient ainsi partager une interface commune ; en somme, elle aiderait à standardiser un peu les choses.

Patrick Allaert répond que ceci pourrait se faire via une extension PECL, et qu’il ne voit pas l’intérêt de l’implémenter dans le core de PHP ; après tout, une interface pourrait tout à fait être partagée entre différents projets, même si elle n’est pas native à PHP.

En conclusion, il en ressort plusieurs avis disant que définir ce type d’interfaces fait parti du rôle du FIG - Framework Interoperability Group, et pas d’internals@.

Sara Golemon annonce la RFC Modify tempnam() to handle directories and auto-cleanup, dont l’idée est de permettre une suppression automatique des fichiers temporaires créés depuis des scripts PHP.

Viennent enfin quelques travaux autour de l’amélioration de performances, notamment autour de Phar + APC, des generators, ou de finally.

Au moment où PHP-5.5-alpha1 est sortie, les fonctions *_logo_*() n’y figurent plus ; cela dit, qui sait ? Il reste encore du temps avant la sortie de la première version stable, et les choses peuvent encore bouger. ↩