Chacun sait, du moins je l'espère, que PHP est un langage interprété et que par défaut, à chaque fois que que du code PHP est exécuté, il est tout d'abord analysé puis transformé en un langage intermédiaire connu sur le nom de bytecode et enfin réellement exécuté par la machine via le Zend Engine.
Or, dans la plupart des cas, le temps nécessaire à l'analyse du code et à sa conversion en bytecode est largement supérieur au temps nécessaire à la machine pour exécuter le code ainsi obtenu.
Pour remédier à cela, des outils ont été développés afin que les étapes d'analyse et de conversion en bytecode ne soient pas effectuées à chaque exécution du code, mais une seule fois, lors de la première exécution, ce qui permet donc d'améliorer grandement les performances du langage.
En conséquence, la majorité des sites propulsés par PHP utilisent ce type d'outil, d'autant plus qu'ils sont relativement facile à installer et configurer et ont donc un coût de mise en œuvre très réduit, ce qui les rend encore plus séduisants.
Le plus connu de ces outils s'appelle APC, aka Alternative PHP Cache et est développé entre autre par Rasmus Lerdorf, le concepteur originel.
Cependant, malgré le fait que Rasmus participe à son développement et que sa documentation soit disponible sur le site php.net, il ne s'agit toujours que d'une extension de PHP.
Donc, même si son fonctionnement est très dépendant du fonctionnement du langage et qu'elle est donc développée parallèlement au langage, elle n'est en aucune façon développée simultanément.
C'est la raison pour laquelle la dernière version officielle d'APC n'est pas du tout compatible avec PHP 5.4, et que si votre site dépend de lui, il est pertinent de rester encore un peu sur une version antérieure du langage le temps que APC soit mis à jour.
Cette mise à jour devrait d'ailleurs être disponible à court terme, la version de développement d'APC se révélant déjà beaucoup plus stable que la version officielle avec PHP 5.4.
Cependant, même si le paquet Dotdeb correspondant est disponible sous le nom php5-apc, il ne s'agit toujours que d'une version de développement, et il est donc très fortement déconseillé de l'utiliser dans le cadre d'un environnement de production, sous peine d'avoir potentiellement des ennuis plus ou moins importants.
À plus ou moins moyen terme, cette situation ne devrait toutefois pas pouvoir se reproduire.
En effet, la possibilité d'intégrer complètement APC à PHP a été évoqué à plusieurs reprises au cours du développement de PHP 5.4, mais les problèmes posés par ce dernier à APC n'ont pas pu être résolu suffisamment vite pour que cela soit possible.
Pour autant, chose suffisamment rare pour être signalé, il semble y avoir un consensus parmi les développeurs de PHP sur le fait que APC devra un jour faire parti du langage et ne plus être une extension, même si certains d'entre eux s'inquiètent de la situation de monopole par défaut
que cela impliquerait et du manque de visibilité que cela engendrerait pour les autres solutions disponibles sur le marché.
6 réactions
1 De Jean-Marc Fontaine - 29/03/2012, 14:11
Une précision puisque c'est notre échange qui t'a donné l'envie d'écrire ce billet : je ne migre pas vers PHP 5.4. Je suis en train de prototyper un applicatif qui ne devrait pas sortir avant l'automne. J'ai donc (normalement) de la marge.
Concernant cette crainte d'un monopole d'APC, je trouve que c'est prendre le problème à l'envers. A mon sens, le vrai souci que par défaut PHP ne met pas en cache son OP Code ce qui est une problème de conception de PHP lui-même.
2 De Cyrano - 29/03/2012, 15:17
« Concernant cette crainte d'un monopole d'APC, je trouve que c'est prendre le problème à l'envers. »
Je me demande s'il est surtout pertinent de parler de monopole : Est-ce qu'on ne cherche pas tous plus ou moins d'abord un standard sur lequel s'appuyer pour nos développements ? L'autre question à poser serait : quelles sont les alternatives à APC et s'en démarque-t-il une ou plusieurs par de meilleures performances ?
Je comprend que ça puisse être très décevant pour ceux qui développent les alternatives, mais il reste peut-être possible même en intégrant APC directement dans le langage de le désactiver pour permettre l'utilisation d'un autre système. Mais, et notez bien que je n'y connais strictement rien et que je dis donc peut-être une ânerie, l'intégration d'APC dans le langage le rendrait peut-être encore plus performant, ce qui relèguerait les alternatives au chapitre de la masturbation intellectuelle.
L'avis des experts sur cette observation ?
My 2¢
3 De OPi - 01/04/2012, 15:36
"Chacun sait, du moins je l'espère, que PHP est un langage interprété [...]".
Je persiste à répéter que PHP est un langage compilé !
http://www.siteduzero.com/forum-83-...
http://www.developpez.net/forums/d9...
4 De mageekguy - 01/04/2012, 16:08
@OPi : Tu peux persister, ça ne veut pas dire que tu as raison.
À un moment ou un autre, tout code lisible par l'humain (comprendre qui n'est pas du langage machine) est forcément compilé.
Dans le cas d'un langage compilé, la compilation a lieu une fois, et l'exécutable obtenu est évidemment directement exécutable, sinon, la compilation n'aurait aucun sens.
Dans le cas d'un langage interprété, le code n'est jamais directement exécutable et nécessite une compilation, transparente pour l'utilisateur mais qui à un coût en terme de performance, à chaque fois qu'il doit être exécuté.
Les langage compilés sont souvent plus efficace que les langages interprétés, car la phase de compilation n'a lieu qu'une seule fois, et qu'en plus, du fait que le temps ne soit pas une contrainte, elle génère un code machine beaucoup plus efficace que celui issue de la compilation d'un langage interprété.
En effet, dans ce dernier cas, la compilation doit être la plus rapide possible, et il n'est donc pas possible de prendre le temps d'analyser finement l'ensemble du code source et d'optimiser aux petits oignons le langage machine obtenu.
Pour autant, des gens très intelligents ont fait en sorte d'améliorer les performances des langages interprétés et ont développé la compilation JIT, par exemple, et il est maintenant possible qu'un langage interprété, sur des tâches spécifiques, soit tout aussi efficace qu'un langage compilé, voir même plus rapide.
PHP est donc bel et bien un langage interprété, puisqu'il y a compilation à chaque exécution du code.
5 De OPi - 01/04/2012, 16:48
Je ne compte pas polémiquer, mais évidemment je ne suis pas d'accord avec tes explications (enfin je suis d'accord avec des faits évoqués, mais pas les conclusions qui en sont tirées). Je crois qu'une des raisons est que l'on ne s'entend pas sur la notion d'interpréteur, qui pour moi est un programme qui analyse, transforme puis exécute un source plus moins ligne par ligne. Alors qu'un compilateur est un programme qui traduit un source dans son entièreté d'un langage dans un autre. Après une des questions fondamentales est de savoir qui exécute et quoi.
Dans quelle catégorie classes-tu C, C++, Java, JavaScript, Perl, Python... et les langages que tu veux ?
Je poste juste ce message car je suis étonné de ta réponse alors que mon message est passé à la trappe !
6 De Amaury Bouchard - 10/04/2012, 16:21
Comme Jean-Marc, je considère aussi que le cache d'opcode devrait être intégré au langage. Il s'agit de quelque chose de fondamental pour l'utilisation de PHP en environnement professionnel ; c'est bien le sujet de ce post.
Je n'ai pas d'exemple en tête, mais je pense qu'il y a d'autres précédents, avec des bibliothèques PECL qui ont été intégrées dans le core language.
On pourrait imaginer que d'autres projets puissent être utilisés en remplacement d'APC, en offrant des fonctionnalités supplémentaires et/ou différentes.
Ce serait un peu comme de pouvoir changer l'implémentation des tables de hashage de PHP. Il y a des cas ultra-spécifiques où ça pourrait faire gagner des performances de folie, mais dans l'écrasante majorité des cas, on est tous bien contents de l'implémentation fournie.