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...

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.

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 ?

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.

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 ?

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.

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.

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").

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.

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.