Je sais que vous peut minifier PHP, mais je me demande si cela a un sens. PHP est un langage interprété, il fonctionnera donc un peu plus lentement qu'un langage compilé. Ma question est la suivante : les clients verraient-ils une amélioration visible de la vitesse de chargement des pages et autres si je réduisais mon PHP ?
Par ailleurs, existe-t-il un moyen de compiler PHP ou quelque chose de similaire ?
PHP est compilé en bytecode, qui est ensuite interprété sur quelque chose qui ressemble à une VM. Beaucoup d'autres langages de script suivent le même processus général, y compris Perl et Ruby. Ce n'est pas vraiment un langage interprété traditionnel comme, par exemple, le BASIC.
Il n'y aurait pas d'augmentation effective de la vitesse si vous essayiez de "minifier" la source. Vous obtiendrez une augmentation majeure en utilisant un cache de bytecode comme APC .
Facebook a introduit un compilateur nommé HipHop qui transforme les sources PHP en code C++. Rasmus Lerdorf, l'un des grands noms de PHP a fait une présentation pour Digg plus tôt cette année qui couvre les améliorations de performance données par HipHop. En bref, ce n'est pas beaucoup plus rapide que d'optimiser le code et d'utiliser un cache bytecode. HipHop est excessif pour la majorité des utilisateurs.
Facebook a aussi récemment dévoilé HHVM une nouvelle machine virtuelle basée sur leur travail de création de HipHop. Elle est encore assez récente et il n'est pas certain qu'elle apporte une amélioration majeure des performances au grand public.
Juste pour être sûr que c'est dit expressément, veuillez lire cette présentation dans son intégralité. Il indique de nombreuses façons d'évaluer et de profiler le code et d'identifier les goulots d'étranglement à l'aide d'outils comme les suivants xdebug et xhprof également de Facebook.
Notez que l'ensemble du bytecode/vm ne vous apporte rien sans un cache de bytecode externe( !). Je ne comprends pas pourquoi PHP jette le bytecode par défaut...
J'imagine que c'est un problème d'hébergement partagé. APC est inclus par défaut dans PHP depuis l'ancien tronc basé sur 6.0. Je ne suis pas sûr que nous le verrons par défaut dans la 5.4 ou quel que soit le nom du nouveau tronc...
Merci beaucoup pour ces informations. Malheureusement, je n'ai pas le contrôle total de mon serveur (il est loué). Est-il probable que les hôtes web utilisent APC ?
Abandonnez l'idée de réduire PHP au minimum et préférez l'utilisation d'un cache d'opcode, tel que PHP Accelerator ou APC .
Ou quelque chose d'autre comme memcached
Memcached est un moyen parfaitement cromulent d'améliorer les performances... après avoir effectué une analyse comparative et un profilage et établi que la mise en cache elle-même sera le meilleur gain de performance possible.
Si vous utilisez PHP 5.5, vous n'avez pas besoin d'installer de cache pour les opcodes car il est fourni par défaut.
Avec un peu de réécriture (noms de variables plus courts), vous pouvez économiser quelques octets de mémoire, mais c'est aussi rarement significatif.
Cependant, je conçois certaines de mes applications d'une manière qui permet de concaténer des scripts d'inclusion ensemble. Avec php -w il peut être compacté de manière significative, ajoutant un petit gain de vitesse pour le démarrage du script. Sur un serveur compatible avec l'opcode, cela ne permet cependant que d'économiser quelques vérifications de mtime de fichiers.
Il s'agit moins d'une réponse que d'une publicité. Je travaille sur une extension PHP qui traduit les opcodes Zend pour les exécuter sur une VM avec un typage statique. Cela n'accélère pas le code PHP arbitraire. Il vous permet d'écrire du code qui s'exécute bien plus rapidement que ce que le PHP normal permet. La clé ici est le typage statique. Sur un CPU moderne, un langage dynamique mange les pénalités de mauvaise prédiction de branche à gauche et à droite. Le fait que les tableaux de PHP soient des tables de hachage impose également un coût élevé : beaucoup de mauvaises prédictions de branche, une utilisation inefficace du cache, une mauvaise prélecture de la mémoire, et aucune optimisation SIMD. Les mauvaises prédictions de branche et les manques de cache en particulier sont le talon d'Achille des processeurs d'aujourd'hui. Ma petite VM contourne ces problèmes en utilisant des types statiques et des tableaux C au lieu de tables de hachage. Le résultat est une exécution environ dix fois plus rapide. Ceci utilise l'interprétation du bytecode. L'extension peut optionnellement compiler une fonction à travers gcc. Dans ce cas, vous obtenez une vitesse deux à cinq fois supérieure.
Voici le lien pour les personnes intéressées :
https://github.com/chung-leong/qb/wiki
Encore une fois, l'extension n'est pas un accélérateur général de PHP. Vous devez écrire du code spécifique pour elle.
Il existe des compilateurs PHP... voir cette question précédente pour obtenir une liste ; mais (à moins que vous n'ayez la taille de Facebook ou que votre application ne soit destinée à être exécutée côté client), ils posent généralement beaucoup plus de problèmes qu'ils n'en valent la peine.
Une simple mise en cache des opcodes vous apportera plus de bénéfices pour l'effort demandé. Vous pouvez aussi profiler votre code pour identifier les goulots d'étranglement, puis l'optimiser.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
0 votes
Un point évident est l'obfuscation, pour rendre votre code moins portable, ce qui peut être un objectif valable.
0 votes
Un autre point est l'économie d'espace serveur (si c'est important),