Ce mois-ci sur internals@php - Mai 2014

This post is also available in English.

Le mois de mai 2014 qui vient de se terminer a vu 816 messages sur la mailing-list internals@ de PHP. Après un mois d’avril bien calme, on repart sur un volume d’échanges nettement plus important !

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) :

Avant tout : la sortie de PHP 5.6 continue d’approcher : Ferenc Kovacs a annoncé la bêta 2 le 2 mai. Et elle a été suivie de la bêta 3 le 15.

Alors que le mois venait tout juste de commencer, Dmitry Stogov a commencé à parler d’une série de modifications, nommées phpng, qui permettrait un gain de performance allant de 10% à 30% selon les applications.

Le constat initial partait du fait que le moteur d’exécution de PHP travaille avec des structures de données demandant sans cesse d’effectuer des allocations/libérations mémoire et du comptage de références – une application PHP typique pouvant passer 20% de son temps CPU en gestion de mémoire, 10% en manipulation de HashTables, 30% en fonctions internes et seulement 30% dans la VM. Une amélioration serait donc de modifier les structures de données utilisées en interne, en vue de minimiser les allocations mémoires.

Cela signifie un gros travail de refactoring (4 mois de travail) sur le moteur de PHP, qui améliore les performances, l’utilisation mémoire et pose les premières briques qui pourront servir de fondations à d’autres améliorations futures, comme la mise en place de compilation JIT.

Ce travail n’est bien sûr pas terminé (il demanderait encore quelques mois avant de pouvoir être présentable en version alpha), mais il a rapidement été suggéré qu’il pourrait s’agir d’un gros point pour PHP 6 – qui est prévue pour dans quelque chose comme deux ans.

Là où phpng ne devrait pas avoir d’impact sur le comportement tel qu’il est vu côté utilisateur, il faudrait par contre repasser sur l’ensemble des extensions PHP existantes en vue de les adapter (les changements sur les structures de données utilisées en interne par PHP sont à prendre en compte au niveau des extensions, celles-ci étant assez proches de PHP lui-même). En vue de documenter la migration vers phpng pour les développeurs de PHP ou d’extensions, une page wiki a d’ailleurs été mise en place : Upgrading from PHP5 to NG.

Dans la conversation est revenue l’idée qu’il serait intéressant de se débarrasser des vieilles SAPIs – certains allant jusqu’à suggérer de ne plus supporter mod_php, qui gagne souvent à être remplacé par Apache/mod_fcgid ou nginx/php-fpm. Toutefois, même si ces derniers suivent une architecture mieux conçue, n’oublions pas que changer un composant a un coût.

Pierre Joye a rapidement noté que la branche phpng entrait en conflit avec le travail effectué depuis plusieurs mois sur le fonctionnement de PHP en 64 bits (qui n’a pas été intégré à la branche PHP 5.x car apportant trop de modifications). En vue d’éviter que ce type de cas de figure se reproduise, il faudrait grandement améliorer la communication – de plus, travailler sur un mode ouvert permettrait à plus de développeurs d’intervenir.

Il a ensuite posté quelques chiffres indiquant comment la branche 64bits impactait l’utilisation mémoire : entre 2% et 5.5% de mémoire utilisée en plus sur des applications réelles. L’impact relatif serait plus important avec les modifications apportées par la branche phpng, celle-ci ayant revu plusieurs structures de données internes. En complément pour ceux qui voudraient en savoir plus, voici quelques notes sur le but de cette branche.

Dans la foulée, Anatol Belski a annoncé en milieu de mois l’ouverture des votes sur la RFC correspondante : 64 bit platform improvements for string length and integer in zval. Dans la discussion, Ferenc Kovacs a résumé une partie du problème : d’un côté, phpng vise à améliorer les performances et à réduire l’occupation mémoire, alors que la branche 64bits vise à améliorer les typages internes tout en augmentant celle-ci.

Constatant que les discussions tournaient en rond et n’étaient plus réellement constructives, Nikita Popov a proposé de trouver un terrain d’entente, en mettant en place certaines des évolutions apportées par la branche 64bits (entiers en 64 bits, tailles non-signées, size_t pour les longueurs de chaînes) mais sans pour autant basculer en 64 bits là où c’est le plus coûteux en mémoire et le moins intéressant en fonctionnalité (numéros de lignes, nombres de paramètres, tailles de HashTables).

Cette proposition a été plutôt bien accueillie. Comme l’a souligné Rasmus Lerdorf, la solution est cohérente et prend en compte le travail effectué des deux côtés. En raison de problèmes au niveau de la mailing-list, une nouvelle RFC n’a pas pu être soumise immédiatement et devrait arriver prochainement.

En fin de mois, alors qu’un post rédigé par Joe Watkins à propos de phpng était apparu sur php.net, Ferenc Kovacs a demandé ce qu’il fallait en faire : le conserver tel quel, le supprimer, le ré-écrire afin qu’il soit plus formel et plus factuel, ou poster un autre article expliquant que ce premier était encore sujet à controverses et qu’il s’agissait plus de l’avis personnel d’un développeur que d’une déclaration officielle.

Plusieurs ont exprimé leur surprise quant à la mise en ligne de cet article, php.net n’ayant pas pour but de jouer un rôle de blog personnel. De plus, pas mal de sites ayant repris la nouvelle, simplement supprimer celle-ci ne semblait pas forcément être la meilleure approche pour tous – mais, en même temps, il est probablement bien trop tôt pour commencer à parler de ces évolutions de manière officielle et cet article n’était d’après certains pas vraiment formulé de manière objective ni professionnelle.

Toutefois, comme l’a souligné Philip Sturgeon, plusieurs sites à fort trafic avaient déjà commencé à parler de phpng – sans nécessairement parvenir à résumer avec succès ce dont il s’agit et les implications futures pour PHP (et, bien sûr, parler de PHP en termes peu flatteurs est souvent un bon moyen pour générer du trafic).

Levi Morrison a ensuite apporté quelques explications quant à l’origine de cet article : alors que “phpng” faisait parler de lui dans la communauté, apporter quelques éclaircissements était en soit une idée raisonnable. En quelque sorte, il pouvait s’agir d’une tentative de communication auprès des développeurs utilisant PHP, autour de ce qu’il se passait sur internals@¹ ; et essayer d’avancer n’est jamais facile.

Joe Watkins a complété en indiquant qu’il n’avait pas souhaité poster une news sur php.net mais qu’il visait à lancer un blog de développeurs. Cette idée, d’ailleurs, est un peu liée à un des rôles de planet-php. En fait, cette idée de “blog de développeurs” parlant de ce qu’il se passe autour du développement de PHP et d’internals@, c’est un peu ce qu’il me manquait quand j’ai commencé à poster ces dépilages – même s’il serait intéressant d’avoir des articles allant plus au fond des choses, moins en mode “résumé”.

Finalement, Zeev Suraski a supprimé l’entrée de la page d’accueil de php.net pour lui retirer un peu de visibilité, tout en laissant l’article sur la page d’archives 2014 – ce qui était la chose à faire pour pas mal de monde.

Dmitry Stogov a rédigé la RFC: Fast Parameter Parsing API qui vise à mettre en place une solution alternative, plus rapide, à zend_parse_parameters()² pour la lecture des arguments d’une fonction ou méthode.

En pratique, introduire une grande quantité de nouvelles macros et une syntaxe plus verbeuse semble en intéresser certains, mais d’autres ont fait remarquer que cela rendait aussi le code plus lourd à écrire. Comme l’a souligné Pierre Joye, il serait bon d’améliorer les API internes : une base de code plus agréable faciliterait le travail sur les 10 prochaines années.

D’un autre côté, un gain de quelques pourcents (entre 2% et 5%) au niveau des performances, en ne modifiant que les fonctions les plus importantes… Il faudrait d’ailleurs que la RFC insiste sur le fait qu’il ne s’agit de modifier qu’une petite partie des fonctions de PHP.

Stas Malyshev a annoncé que la RFC: Keeping PHPT Tests Green était passée, avec 16 votes pour et aucun vote contre. En cas de test ne passant plus, les deux solutions qui ressortent sont d’annuler les modifications problématiques au bout de deux jours ou de mettre à jour les tests. Bien sûr, la seconde option ne doit être retenue que lorsque le nouveau comportement est attendu.

Dans les jours qui ont suivi, Stas Malyshev a envoyé des mails lorsque des modifications cassaient le build, demandant à ce que les problèmes correspondant soient corrigés. Les réactions ont été plutôt bonnes et la stabilité ne peut qu’en être améliorée.

Andrea Faulds a rappelé que pour passer, une RFC avait besoin de 50%+1 votes “pour” – et de 2/3 de votes “pour” dans le cas d’une modification impactant le langage en lui-même. Cela dit, il notait que la distinction “changement impactant le langage” n’était pas toujours claire et qu’une majorité de 50%+1 signifiait que des RFC pouvaient passer à une très faible majorité.

En conséquence, il a proposé que toutes les RFC aient désormais besoin de 2/3 de votes “pour” pour être acceptées. De la sorte, seules les modifications réellement bien acceptées par les développeurs passeraient (en pratique, toutes les RFC passées pour PHP 5.6 avaient au moins 2/3 de “pour” – cette proposition ne constituerait donc pas un réel frein au progrès).

Zeev Suraski a répondu que 50%+1 était selon lui suffisant pour des modifications sur des extensions, des fonctions, des numéros de versions – en somme, des points précis n’impactant pas la direction générale de PHP. Par contre, il lui semblerait intéressant que seuls les développeurs réellement concernés par une modification votent sur celle-ci (par exemple, ceux travaillant sur le moteur voteraient pour une modification centrale, alors que ceux travaillant sur la documentation interviendrait en cas de changement sur celle-ci). Toutefois, comme l’a fait remarquer Andrea Faulds, les changements sur la couche Zend vont avoir tendance à impacter tout le monde.

En fait, comme noté par Dmitry Stogov, certaines modifications au niveau du moteur demandent une réelle expertise technique pour être comprises. Expertise technique qui pourrait aider à arriver à de meilleures solutions – ce qui commence à se faire, puisque plusieurs RFC récentes ont été rédigées par des équipes de plusieurs développeurs, avec de nouveaux arrivant guidés par des plus anciens.

Finalement, au vu des échanges, il est probable que ces 50%+1 et 2/3 restent comme ils sont aujourd’hui – mais que la distinction entre les deux types de RFC soit éclaircie.

Quelques échanges sont venus compléter la discussion tournant autour de la RFC: Return Type Declarations. En particulier, la syntaxe proposée a l’avantage d’être similaire à celle d’autres langages ainsi que d’être compatible avec celle retenue par Hack.

Josh Watzman a posté quelques retours où il relevait quelques incompatibilités entre cette RFC et l’implémentation choisie pour Hack. En particulier, Hack utiliserait this comme type de retour là où PHP partirait plutôt sur self.

Alors que des points de vue différents ont parfois été exprimés assez brutalement, Levi Morrison a rappelé que même si chacun pouvait avoir une vision différente de la manière dont il est possible d’améliorer PHP, le but de tous était le même – et a dressé une rapide liste de quelques points qu’il jugeait acceptables ou non.

Martin Keckeis a proposé que PEAR ne soit plus intégré aux sources de PHP. Toutefois, comme répondu par Hannes Magnusson, PEAR permet aussi l’installation d’extension PECL – ce qui signifie qu’il n’est pas possible de s’en passer pour l’instant.

Michael Wallner a indiqué avoir commencé à réfléchir au chargement d’extensions dépendant les unes des autres (aujourd’hui, c’est à l’utilisateur de se débrouiller pour charger ces extensions dans le bon ordre). Julien Pauli a répondu que quelque chose avait été commencé sur le sujet il y a quelques temps et qu’il pourrait être intéressant de mettre ces idées en commun. En fait, comme l’a souligné Hannes Magnusson, le mécanisme d’extensions aurait peut-être besoin de plus d’améliorations que ce seul point !

Sara Golemon a rédigé la RFC: Add typehint accessors to ReflectionParameter qui vise à améliorer la façon dont sont gérés les type-hints par la Reflection. Levi Morrison a souligné qu’il pourrait être intéressant de voir ce que donnent les deux RFC sur les types de retours et les types nullables ; et la RFC a été mise à jour en conséquence.

Sara Golemon a aussi rédigé la RFC: Fix handling of custom session handler return values – la correction correspondante cassant la compatibilité antérieure, une RFC peut être nécessaire (ne serait-ce que pour déterminer pour quelle version de PHP cette modification pourrait être apportée).

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.