Optimiseur de sources PHP

par **Hubert Roksor** » 18 mai 2007, 21:52

Idéalement, l'opcode cache peut optimiser certains trucs à son niveau (des variables temporaires utilisées en interne, etc...). Si je le fais en PHP c'est non seulement parce que c'est le seul langage que je maîtrise mais aussi parce que c'est plus facile à utiliser, distribuer, maintenir, partager. Et puis c'est pas prévu pour être utilisé à la volée, j'aimerais bien être capable de scanner tous les fichiers d'un répertoire pour capturer toutes les constantes de classes et faire du constant-folding un peu partout.

par **Sékiltoyai** » 18 mai 2007, 21:38

Pour ma part, je n'ai pas de grandes idées, je ne suis pas excellent codeur, et je ne sais pas exactement comment se comporte le noyau php. Mais par contre j'ai une grande question : est-ce que c'est vraiment nécessaire de le faire en php ? Comment sera vue l'application, comment sera-t-elle intégrée, et exécutée ?
Disons que :
- Celui qui veut optimiser ses sources PHP a forcément de quoi interpréter du PHP, donc on est sûr que l'appli fonctionnera.
- On est forcément plus performants en PHP que dans un autre langage, question d'habitude.
- PHP dispose de son tokenizer et de tout de qu'il faut «out of the box» pour analyser des sources PHP. Refaire un parser n'est pas passionnant.

Ok, j'avais pensé à un module en c (le c, c'est loin d'être compliqué quand même), mais le faire en php est défendable.

par **Hubert Roksor** » 18 mai 2007, 21:05

Voir la méthode getDocComment() des classes Reflection* sur http://php.net/manual/language.oop5.reflection.php

Ceci impliquant que les «doc comments» sont conservés au runtime, et donc qu'on gagnerait à les supprimer si on n'en a pas besoin. À tester.

Pour être honnête j'avais oublié qu'on pouvait faire ça (même si je me rappelle l'avoir déjà lu ça m'était sorti de la tête). Donc effectivement ça donne une raison supplémentaire de les enlever et une raison supplémentaire de pouvoir dés/activer chaque optimisation séparemment

De toute façon je compte m'orienter vers un système à la GCC. La mauvaise nouvelle pour moi est que j'avais classé dans mon esprit la suppression des commentaires dans la catégorie "safe" alors qu'à l'évidence elle ne l'est pas toujours (donc elle ne l'est pas, "safe").

par **naholyr** » 18 mai 2007, 20:45

Pour ma part, je n'ai pas de grandes idées, je ne suis pas excellent codeur, et je ne sais pas exactement comment se comporte le noyau php. Mais par contre j'ai une grande question : est-ce que c'est vraiment nécessaire de le faire en php ? Comment sera vue l'application, comment sera-t-elle intégrée, et exécutée ?

Disons que :
- Celui qui veut optimiser ses sources PHP a forcément de quoi interpréter du PHP, donc on est sûr que l'appli fonctionnera.
- On est forcément plus performants en PHP que dans un autre langage, question d'habitude.
- PHP dispose de son tokenizer et de tout de qu'il faut «out of the box» pour analyser des sources PHP. Refaire un parser n'est pas passionnant.

par **naholyr** » 18 mai 2007, 20:40

commentaires phpdoc qui sont parfois très importants pour le runtime (une librairie comme ezpdo par exemple les utilise activement) ?
Ça j'ai pas vraiment compris, les commentaires n'existent pas pour le runtime. L'idée c'est de garder ses sources 100% clean, avec tous les commentaires qu'on veut et déployer la version "optimisée". Est-ce que ezpdo lit ses propres sources durant son exécution ?

PHP5 a des fonctions d'introspection dans l'objet, et les commentaires «phpdoc» font intégralement partie de la classe. À ce titre on peut les extraire sans avoir à «parser» le fichier mais de façon tout-à-fait propre.
Un bel exemple d'utilisation est ezpdo : http://www.ezpdo.net/blog/?p=5#the_base_class

Voir la méthode getDocComment() des classes Reflection* sur http://uk2.php.net/manual/fr/language.o ... ection.php

Ceci impliquant que les «doc comments» sont conservés au runtime, et donc qu'on gagnerait à les supprimer si on n'en a pas besoin. À tester.

par **Sékiltoyai** » 18 mai 2007, 20:03

Pour ma part, je n'ai pas de grandes idées, je ne suis pas excellent codeur, et je ne sais pas exactement comment se comporte le noyau php. Mais par contre j'ai une grande question : est-ce que c'est vraiment nécessaire de le faire en php ? Comment sera vue l'application, comment sera-t-elle intégrée, et exécutée ?

par **Hubert Roksor** » 18 mai 2007, 17:51

Tant que j'y suis, je spamme un peu le topic avec mes questions existentielles actuelles. Concernant le parser, j'ai le choix entre essayer d'utiliser Parse_Tree (voir plus haut) ou faire mon propre parser basé sur le tokenizer de PHP. Vous devez vous demander "pourquoi s'embêter avec une extension PECL ?". Cette approche a deux avantages : premièrement, ça me libère de la maintenance du parser. C'est quelqu'un d'autre qui s'en occupe, j'imagine que son créateur (William Candillon) va continuer à travailler dessus et à l'améliorer (j'ai remarqué un certain intérêt pour le projet de la part de certains blogger). Ensuite, posséder une représentation XML du code source me permettrait d'utiliser XPath plutôt que de devoir inventer ma propre manière d'exprimer les optimisation à effectuer. Par exemple, détecter un cas comme

$var = strtolower(strtolower($var));

L'exemple n'est peut-être pas idéal, mais si je pouvais formuler les optimisations PHP en expression XPath ça me donnerait l'impression de parler Esperanto et accessoirement pouvoir transformer les sources par XSLT. D'un autre côté, je suis de moins en moins certains de pouvoir tout exprimer/détecter via XPath donc j'en suis au même point qu'au départ, d'où stalling.

par **Hubert Roksor** » 18 mai 2007, 17:37

D'ailleurs tiens puisque le sujet revient d'outre-tombe, pour tout ce qui est constant folding & cie je comprends, mais supprimer les commentaires et les whitespaces, est-ce que ça n'a pas fondamentalement aucun intérêt vu que les scripts sont "pré-compilés en mémoire"

Retirer les commentaires/whitespaces a un faible intérêt si jamais le script en question sort de l'opcode cache (s'il est délesté, si la machine est relancée, etc...) et doit être recompilé. On pourrait également imaginer que le déploiement d'un script serait plus rapide sans les commentaires (plus rapide à uploader, première compilation plus rapide). Comme je le disais, la gain est infinitésimal.

commentaires phpdoc qui sont parfois très importants pour le runtime (une librairie comme ezpdo par exemple les utilise activement) ?

Ça j'ai pas vraiment compris, les commentaires n'existent pas pour le runtime. L'idée c'est de garder ses sources 100% clean, avec tous les commentaires qu'on veut et déployer la version "optimisée". Est-ce que ezpdo lit ses propres sources durant son exécution ?

par **Hubert Roksor** » 18 mai 2007, 17:31

où ca en est ?

Pas beaucoup plus loin qu'au début. J'ai essayé plusieurs prototypes mais je n'arrive pas à me décider sur la manière d'attaquer la chose. Il faut dire que je cherche quelque chose d'assez exhaustif et capable d'un large champs de modifications le tout avec un minimum de risque. J'avais pas mal laissé tomber depuis quelques mois faute de temps et de ressources (j'attendais de voir Parse_Tree chez pecl4win) mais j'étais justement en train de m'y remettre un peu.

Si tu as des idées sans être sûr de pouvoir les mettre en pratique, ce que tu peux faire c'est réfléchir à des optimizations possibles et les décrire sur le forum. On pourrait alors discuter de leur viabilité, des risques associés (effets secondaires) ou leur champs d'application.

par **Sékiltoyai** » 18 mai 2007, 16:38

Bah de toute facon, il faudra laisser l'option de ne faire que les optimisations que l'on désire, donc du coup, ne retirer les commentaires que si l'utilisateur le demande...

par **naholyr** » 18 mai 2007, 16:31

D'ailleurs tiens puisque le sujet revient d'outre-tombe, pour tout ce qui est constant folding & cie je comprends, mais supprimer les commentaires et les whitespaces, est-ce que ça n'a pas fondamentalement aucun intérêt vu que les scripts sont "pré-compilés en mémoire" (et donc certainement que les commentaires & whitespaces n'ont d'influence qu'au premier chargement) ?
Et comment tu vas gérer les commentaires phpdoc qui sont parfois très importants pour le runtime (une librairie comme ezpdo par exemple les utilise activement) ?

par **Sékiltoyai** » 18 mai 2007, 14:36

J'attend de voir les fichiers, et de voir si la compréhension est très très très difficile ou juste difficile... et quand je dis peu de temps, ça veut dire 2 à 4 h par semaine, c'est déja raisonnable je pense pour aider (au pire je me rabaisserai au poste de bête-testeur

Idem. C'est un projet intéressant mais je ne sais pas si j'aurais la trempe et le temps pour aider vraiment, mais je peux peut être tout de même aider un peu si c'est nécessaire...
Mais par contre, comme disait jojolapine, où ca en est ?

par **Ultim4T0m** » 01 janv. 2007, 15:39

Même si ce n'est pas grand chose, as-tu pensé à remplacer les fonctions rand() par des mt_rand() ?

Il me semble avoir lu qu'elle était plus rapide (un chiffre assez important d'ailleurs) dans le bouquin de Cyruss ^^

Sinon, projet très intéressant, mais je n'ai pas encore le niveau pour apporter quoi que ce soit d'utile je pense, donc bonnes chances à ceux qui y participent

par **jojolapine** » 29 déc. 2006, 21:35

bon alors d'après ce que j'ai compris, j'ai fait un peu de travail pour pas grand chose
On ne code jamais pour rien, t'as même appris ce qu'était le tokenizer

Que je n'ai pas bien compris d'ailleurs

Sinon pour le reste, le mieux est d'attendre d'avoir le script en main (extrêmement mal documenté à l'heure actuelle) mais si tu n'as que peu de temps tu risques de le perdre principalement à comprendre comment les choses fonctionnent. Comme je disais, ça demande beaucoup d'efforts pour pas grand-chose.

J'attend de voir les fichiers, et de voir si la compréhension est très très très difficile ou juste difficile... et quand je dis peu de temps, ça veut dire 2 à 4 h par semaine, c'est déja raisonnable je pense pour aider

(au pire je me rabaisserai au poste de bête-testeur

par **winni** » 29 déc. 2006, 21:13

Pour moi j'ai déja un type de ce projet en cours, mais il est actuellement sur papier et diffère quand même.

Pour ma part

<?
$var="iuhig";
echo "blapoih $var ifhj";
?>

Devient

<?
$var= 'iuhig';
echo 'blapoih '.$var.' ifhj';
?>

Optimiseur de sources PHP

Répondre

Étendre la vue Revue du sujet : Optimiseur de sources PHP