Discussion :

[MainMa]

Bonjour.

Quelqu'un sait-il s'il y a des benchmarks montrant si le fait de supprimer les nouvelles lignes et espaces inutiles et raccourcir les noms des variables ($a, $b,...) dans un code source PHP a une influence sur les performances de l'application ?

J'ai essayé de faire quelques mesures de performance sur mon propre ordinateur, mais je n'obtiens rien de très clair, c'est pour ça que je demande.
À la louche, il me semble que le temps de lire le fichier .php est négligeable, et que le temps d'exécuter le code n'est quasiment pas influencé par la présence d'espaces. Mais bon, j'aimerais avoir des résultats un peu plus fiables.

[sabotage]

Je n'ai pas trouvé non plus d'élément de réponse mesurés sur le sujet.
Je pense comme toi que l'influence de ces éléments sur les performances est trop faible pour être mesurée en comparaison d'autres facteurs.

Nous ne sommes heureusement plus dans une époque ou nous devons économiser de la mémoire sur le nom des variables.
Il y a beaucoup plus à faire sur l'intelligence du code et la configuration du serveur pour gagner en performance ; et un code clair et bien presenté est un atout bien plus interessant qu'un eventuel millionième de seconde gagné.

[MainMa]

Nous ne sommes heureusement plus dans une époque ou nous devons économiser de la mémoire sur le nom des variables.
Il y a beaucoup plus à faire sur l'intelligence du code et la configuration du serveur pour gagner en performance ; et un code clair et bien presenté est un atout bien plus interessant qu'un eventuel millionième de seconde gagné.

En effet, il ne s'agissait pas de commencer à nommer ses variables comme un barbare. Il s'agit plutôt d'un projet où le code source peut éventuellement au déploiement être transformé pour être sous forme de fichiers plus ou moins illisibles, sans espaces ni sauts de lignes et éventuellement avec les variables renommées.

Après, l'intelligence du code, je fais ce que je peux . Et la configuration des serveurs sur lesquels sera déployé la solution ne dépend pas de moi (puis je ne suis même pas capable de configurer mon propre IIS, du coup il passe 0.8 s./page même pour un Hello World en PHP, terrible !).

[ridick]

je crois que la longueur influence puisque la lecture de tout fichier se fait carractère par carractère mais ça on peut pas le voir puisqu'un fichier php est relativement court et deja pour lire et executer un code php le serveur ne doit pas depasser 30 secondes si deja le decalage est remarquable en lecture du fichier le serveur n'aura meme pas le temps d'executer 10% du fichier

[MainMa]

je crois que la longueur influence puisque la lecture de tout fichier se fait carractère par carractère mais ça on peut pas le voir puisqu'un fichier php est relativement court et deja pour lire et executer un code php le serveur ne doit pas depasser 30 secondes si deja le decalage est remarquable en lecture du fichier le serveur n'aura meme pas le temps d'executer 10% du fichier

Que ça a une influence, la longueur, c'est sûr et certain. Ça se répercute à un moment ou un autre. Le problème était de savoir à quel point l'influence est grande. C'était ça le sens de ma question.

Pour ma part en tout cas, après quelques benchmarks, j'obtiens pour un ensemble de fichiers sur ma machine en moyenne 0.045 s. pour les fichiers en brut et 0.044 s. pour les fichiers avec les lignes vides, commentaires et quelques espaces supprimées. Les résultats étant arrondis au millième. Pas très concluant, surtout que tantôt j'obtiens 0.03 secondes pour les fichiers bruts et 0.09 pour les mêmes "compressés", des fois c'est l'inverse. Bref, à défaut des stats un peu plus sérieux, y a rien à conclure.

J'essaierai peut-être de faire ça sur des échantillons plus grands et en réfléchissant mieux sur la méthode d'évaluation (parce que bon, à ce niveau, un truc de rien du tout t.q. un lancement d'un procès sur l'ordi peut tout fausser).

[metagoto]

Supprimer les espaces, raccourcir les noms des variables (et des symboles en général) ne peut qu'avoir un effet bénéfique en terme de perf. Sauf que ça doit être infinitésimal dans le cadre d'une appli "normale" (pas comme si les fichiers php faisaient plusieurs mega). De plus, avec des caches d'opcodes comme APC, compresser les sources ne servira pas à grand chose.

Ce qui est déjà plus significatif, ce n'est non pas le nombre de "blancs" (commentaires, lignes vides) dans les fichiers, mais le nombre de fichiers chargés avec include/require. Minimiser les accès au disque peut grandement améliorer les perf. Certains frameworks/librairies réunissent tous leurs fichiers en un seul (très) gros fichier pour justement réduire les accès disque.

[MainMa]

Ce qui est déjà plus significatif, ce n'est non pas le nombre de "blancs" (commentaires, lignes vides) dans les fichiers, mais le nombre de fichiers chargés avec include/require. Minimiser les accès au disque peut grandement améliorer les perf. Certains frameworks/librairies réunissent tous leurs fichiers en un seul (très) gros fichier pour justement réduire les accès disque.

C'est prévu également. Actuellement l'application est séparée en une trentaine de fichiers, à prévoir une vingtaine d'autres d'ici peu, et l'idée était aussi de réunir tout ça en trois ou quatre grands fichiers.
Reste que selon les contextes, dans ces cinquante fichiers on a pas forcement besoin de tous à chaque fois (le plus souvent on en charge une dizaine). Ce qui conduit à l'idée de recourir à un cache quelque peu intelligent. Bref.