Voici un petit exemple d'optimisation réalisé. J'ai analysé avec XDebug et WinCacheGrind l'appel à une page. Cette page affiche quelques centaines de lignes provenant d'une table d'une base de données.
Chacune des lignes est affichée avec un partial ce qui me permet d'utiliser le même affichage dans deux pages différentes. Les données de chaque ligne sont accédées via les getters et setters de Zend_Db_Table_Row et Zend_Db_Table_Rowset.
Voici tout d'abord l'analyse de la page sans aucune optimisation.
On constate un temps d'exécution de 488ms. En rouge, j'ai surligné les processus liés aux getters et en jaune ceux liés aux partials. On peut constaté d'ores et déjà qu'ils sont nombreux et au sommet des processus les plus consommateurs.
Voici, ensuite, le résultat après suppression des getters en utilisant des tableaux PHP standard à la place d'objet Zend.
On est passé de 488ms d'exécution à 379ms. Un gain de l'ordre de 20%.
Ci-dessous, la même analyse après l'optimisation des partials et l'utilisation d'includes.
Là, on gagne presque 30% de performance en passant à 225ms de temps d'exécution. Ce qui fait, au total, 50% de gain par rapport au code original.
Voici un petit code qui vous aidera à récupérer le chemin vers vos fichiers de script et donc utiliser un include à la place du helper partial :
$moduleDir = Zend_Controller_Front::getInstance()
->getControllerDirectory('default');
$viewsDir = dirname($moduleDir) . '/views/scripts';
<?include($viewsDir . '/controller/_partial.phtml')?>
Bien entendu, on peut discuter de la manière de faire. Mais ce que j'essaie de démontrer est plutôt la lourdeur des tâches réalisées par Zend. Par exemple, on constate le chargement des plugins, le clonage des variables de la vue, le chargement des helpers, etc... à chaque utilisation de partial()
A utiliser, donc, avec parcimonie et toujours préférer les méthodes efficaces sur des codes récurrents.
