Pour débugger en PHP, il existe maintenant plusieurs extensions pour le moteur de PHP. J'ai choisi xdebug car elle semble la plus complète. Ce qui m'interresse également, c'est le profiling. C'est à dire pouvoir avoir des statistiques sur les temps d'execution de chaque portion de code, ou la mémoire utilisée. N'ayant pas froid aux yeux, j'ai pris la version 2.2 beta car elle offre un truc trés intérressant par rapport à la version stable 1.3 : c'est la génération des données de profiling, au format cachegrind. Cela m'a alors permis d'utiliser le logiciel KCacheGrind, qui est une grande aide pour pouvoir analyser la tonne de données générées avec une application comme une basée sur le framework PHP Copix.

Ce programme est tout bonnement, excellent ! On peut voir graphiquement ce qui prend le plus de temps, afficher les données comme on veut, en détails. Vous pouvez aller voir les captures d'écrans.

Je n'ai pas encore utiliser à fond xdebug et son mode profiling, mais un rapide premier test avec Copix m'a permis de constater une chose au niveau de l'utilisation des includes PHP.

Imaginons un premier cas : j'ai un fichier a.php, qui inclus un fichier b.php, qui inclus lui-même un fichier c.php :

  a.php :
      include (b.php)
   b.php
      include (c.php)

Imaginons dans un deuxième cas, ces mêmes fichiers, tous inclus directement dans a.php :

   a.php :
      include (b.php)
      include (c.php)

Dans le cadre de Copix, j'avais un cas similaire au premier. J'obtenais un coût d'execution sur a.php d'environ 15000 (je crois que c'est en micro seconde). Cela m'avait particulièrement étonné par rapport au cout d'autres scripts faisant des includes simples (donc pas d'include dans un include). J'ai corrigé pour avoir un truc similaire au deuxième. Coût = environ 400. Soit 37.5 fois moins que le premier !!

Certes,ce genre de réarrangement n'est pas toujours faisable, mais je crois que dans Copix 2.3, il y aura de serieuses améliorations au niveau performances :-)

Mise à jour: j'ai du faire une erreur de jugement sur l'interpretation des données, car aprés plusieurs utilisations de xdebug, je n'ai plus remarqué ce genre de bizarreries. Le coût que j'ai constaté, doit être en fait (je ne me rappelle plus), celui de b.php. C'est normal alors qu'il baisse énormément quand j'enleve l'inclusion de c.php dans b.php. Ainsi, le coût de l'instruction include est faible, mais le coût du parsing est énorme, et n'est pas compris dans le coût de l'instruction include mais dans le coût du fichier qui l'inclus.

En tout cas, avoir pu découvrir aussi vite ce genre d'optimisation m'a persuadé d'utiliser dorénavant et systématiquement xdebug et kcachegrind :-)