avril
2008
Souvent on fait des reproches à l’autoload. Cette fonctionnalité PHP permettant de charger automatiquement le fichier contenant une classe, si celui-ci ne l’a pas été au préalable, est vraiment très pratique.
A force d’utiliser beaucoup d’objets, comme c’est le cas pour Zend Framework, on en revient finalement à presque passer son temps à faire des require.
Derick Rethans l’a confirmé : l’autoload prend des ressources supplémentaires, mais il a précisé lors du dernier forum PHP que ceci n’était pas énorme non plus.
Or, peut-être ne le savez vous pas, mais l’autoload peut bel et bien améliorer les performances. Comment ca ?
Et bien, il faut savoir comment PHP fonctionne en interne.
Les étapes principales de PHP sont parsing, compilation, exécution. Dès qu’un require(ou include) est rencontré lors de l’exécution, le Zend Engine s’arrête et commence à parser, compiler, exécuter le fichier en question. Pour peu que celui-ci demande l’inclusion d’un fichier, on peut rapidement descendre en profondeur dans la pile des exécutions, et donc ralentir le traitement.
Dans Zend Framework, qui n’utilise pas l’autoload ( pour lui-même ), nous sommes obligés de faire des require_once en début de chaque fichier, pour inclure les dépendances.
Le problème est qu’un fichier en inclut d’autres, qui en incluent d’autres, qui en ……..
L’empreinte mémoire est donc fortement affectée, car le chargement d’un seul fichier (prenez Zend_Controller_Front, par exemple), entraine le chargement de dizaines d’autres fichiers, qui ne vont pas forcément être utilisés, eux.
L’autoload lui, est légèrement plus gourmand à l’execution pour PHP, mais n’incluera un fichier que si celui-ci est utilisé, alors que le require l’inclut point final.
Au final, autoload prend un peu plus de temps processeur, mais s’il sert à économiser des require ‘inutiles’, alors il peut y avoir un retournement de situation assez spectaculaire.
Dans le développement de Zend Framework, nous avons fait des essais (brouillons), et très souvent, nous notons des gains lorsque l’autoload est activé, voire même des très gros gains ( +88% ). Des gains généraux, c’est à dire autant du coté mémoire, que processeur.
C’est logique, car souvent dans tous les fichiers inclus, seuls quelques-uns vont être utilisés. Sans cache d’OP-Code, tous les autres fichiers alors inclus mais inutilisés, ont été pure perte de performance…
Il nous a déja été demandé, depuis quelques temps maintenant, de n’inclure les fichiers des classes d’exceptions, qu’au moment ou l’exception est lancée, et non au début du fichier source. Ce processus appelé ‘lazy load exception’, a permis d’économiser pas mal de ressources, et donc de permettre aux utilisateurs de servir plus de clients.
Il semblerait que prochainement, nous passions à l’autoload, afin d’encore plus augmenter les performances générales.
5 Commentaires + Ajouter un commentaire
Commentaires récents
Archives
- novembre 2010
- août 2010
- juillet 2010
- juin 2010
- mai 2010
- avril 2010
- mars 2010
- février 2010
- janvier 2010
- décembre 2009
- novembre 2009
- octobre 2009
- septembre 2009
- août 2009
- juillet 2009
- juin 2009
- mai 2009
- avril 2009
- mars 2009
- février 2009
- janvier 2009
- décembre 2008
- novembre 2008
- octobre 2008
- septembre 2008
- août 2008
- juillet 2008
- juin 2008
- mai 2008
- avril 2008
- mars 2008
- février 2008
- janvier 2008
- décembre 2007
- novembre 2007
- octobre 2007
- septembre 2007
- août 2007
- juillet 2007
- juin 2007
- mai 2007
- avril 2007
- mars 2007
- février 2007
Lol, non en effet je n’avais pas fais comme ça. C’est certainement pour sa que mes résultats ne correspondent pas !
Et bien prendre toutes les sources du ZF (environ 4000 fichiers), remplacer tous ses require par des autoloads en début de fichier, et lancer toute la batterie de tests qu’il faut.
Je ne sais pas ce que tu entends exactement par « test du Framework entier sous autoload » ?
On parle bien du test du Framework entier sous autoload n’est ce pas ?
Intéressant ! Moi j’avais fais des petits tests de profiling avec Zend Studio et Zend Framework et j’étais arrivé au résultat inverse
Avec register_autoload: 586.12 ms soit 40.3% du temps d’exécution total
Sans register_autoload: 145.65 ms soit 15.6% du temps d’exécution total
Mais bon sa date du 16 octobre 2007… Donc apparement sa c’est amélioré !