Commit 2007-08-07

J'ai mis au point un nouveau script python qui va nous permettre, à terme, de nous passer du fichier CPU de la batterie. L'idée est d'avoir un moyen automatique pour vérifier le bon déroulement des commits et identifier les problèmes. Ces problèmes peuvent venir du CPU, de la mémoire utilisée qui peuvent subitement augmenter suite à une modif. dont on n'a pas mesuré les conséquences.

Le fichier CPU jouait ce rôle depuis maintenant un bon bout de temps mais il a de nombreux défauts:

• On oublie de le mettre à jour - principalement parce que cette mise à jour peut être laborieuse, surtout quand on ajoute ou retire des nouveaux tests.
• Le fichier grossit et devient difficilement lisible (pas de graphique)
• Le fichier ne concerne qu'une seule machine (chinook). Or on sait que certaines modifs peuvent influencer uniquement un type de machine. De plus, il serait intéressant de comparer les différentes machines entre elles.
• Le système dokuwiki étant bugué (ou protégé contre l'upload abusif?), la mise à jour du fichier excel n'est pas possible à travers le réseau.
• Le fichier CPU ne concerne que le CPU (d'où son nom). Il serait utile de garder trace d'autres grandeurs telles que la mémoire utilisée.

Bref, c'est la galère et, vu la flexibilité du nouveau script de batterie (battery.py), j'ai décidé de coder un système automatique en suivant le même type de schéma, en python.

Pour voir apparaître les beaux graphes sur votre écran, il vous faudra Gnuplot.py (installé dans votre site-packages de python) et gnuplot dans votre PATH. Plus tard, je migrerai certainement le code vers matplotlib qui a l'air franchement mieux fait.

Plusieurs modes de fonctionnement sont possibles. Tapez stats.py en ligne de commande pour avoir l'aide.

La première utilisation est d'extraire une courbe de temps CPU:

stats.py -plot sum apps\verif\CPU-OSF1-All.txt

on appelle la commande sum sur le fichier apps\verif\CPU-OSF1-All.txt et on choisit un graphe gnuplot par l'option -plot. Après avoir fait quelques accès SVN, le script donne ca:

On voit donc l'évolution du temps total de la batterie sur chinook de révision en révision (en abscisse, les numéros de révision et en ordonnée, le temps CPU en secondes). Si quelqu'un est fan de gnuplot, il peut améliorer le graphe pour moi.

Pour ceux qui trouvent ça lent, il peuvent se rassurer: le script met en cache tous les accès SVN (dans le répertoire .cache/) et l'appel suivant est donc beaucoup plus rapide que le premier.

Au cas où les accès SVN coincent, c'est certainement que votre svn est pas bien configuré. Je vous conseille d'ajouter un profil “gaston” dans votre putty, avec identification par clef publique/privée sans passwd et ajouter ces lignes dans votre fichier de config svn:

[tunnels]
ssh = C:/Program Files/putty/plink.exe

Ca dit, en gros que svn (à installer - tortoise ne suffit pas) utilise le ssh de putty (nommé plink.exe).

Avant l'affichage du graphe, le script affiche une belle chiée d'infos sur toutes les versions rencontrées. Vous pouvez les lire: c'est très instructif. En voici un extrait:

...
==== parsing revision #99 by noels on 2007-07-06
      15 largest absolute diffs:
              "apps.imp.long" : -46.5/703.7 (-6.6%)
              "apps.ie.tireSteering" : -45.9/427.9 (-10.7%)
              "apps.imp.taylor3dPk2Diss" : -43.6/2643.2 (-1.6%)
              "apps.qs.elbowModif4b" : -36.8/308.2 (-11.9%)
              "apps.bImp.cyl3D" : -25.7/1375.6 (-1.9%)
              "copraImport.tests.copraProfiling5.profilageUNoSym" : -20.7/1545.0 (-1.3%)
              "apps.bImp.cyl3DVP" : -18.2/885.7 (-2.1%)
              "apps.bImp.cylPlastLineSearchPk2Cons" : +15.6/218.3 (+7.1%)
              "apps.qs.dgShellFullPinchedCylinder" : +14.8/252.4 (+5.8%)
              "apps.bIe.aube3LineSearch" : -14.4/299.4 (-4.8%)
              "apps.bIso.soudureT" : +14.0/782.0 (+1.8%)
              "apps.imp.taylor3dPk2Cons" : -12.9/814.3 (-1.6%)
              "apps.imp.longHoriz" : -12.4/171.9 (-7.2%)
              "apps.ale.forge" : -11.5/102.8 (-11.2%)
              "apps.bIe.aube3" : -11.1/224.8 (-5.0%)
      15 largest relative diffs:
              "apps.qs.elbowModif4b" : -36.8/308.2 (-11.9%)
              "apps.ale.forge" : -11.5/102.8 (-11.2%)
              "apps.ie.tireSteering" : -45.9/427.9 (-10.7%)
              "apps.ale.qsConv03" : -1.2/11.5 (-10.3%)
              "apps.complex.tombeBordEas2D" : -0.8/10.1 (-7.6%)
              "apps.ale.entonnoirAxyAle" : -8.7/116.0 (-7.5%)
              "apps.imp.longHoriz" : -12.4/171.9 (-7.2%)
              "apps.bImp.cylPlastLineSearchPk2Cons" : +15.6/218.3 (+7.1%)
              "apps.imp.long" : -46.5/703.7 (-6.6%)
              "apps.bQs.striction3dQs" : -0.6/8.9 (-6.6%)
              "apps.complex.contact3dDefoDefoAugLag2 (2)" : -4.1/67.5 (-6.1%)
              "apps.complex.contact3dDefoDefoAugLag3 (3)" : -3.8/61.8 (-6.1%)
              "apps.complex.contact3dDefoDefoAugLag2 (3)" : -3.3/54.5 (-6.1%)
              "apps.complex.tay2dExpPk2" : +10.2/171.9 (+5.9%)
              "apps.qs.dgShellFullPinchedCylinder" : +14.8/252.4 (+5.8%)
      "apps.monosMeca.membraneThirdDegree1" is a new test
      "apps.qs.dgSixteenNodeShellPinchedCylinder" is a new test
      "apps.qs.dgSixteenNodeShell" is a new test
      "apps.qs.dgSixteenNodeShellHemisphereWithHole" is a new test
      4 tests added - 0 removed

On voit donc que Ludo a ajouté 4 tests le 6 juillet et on peut voir les 15 plus grandes diffs en valeur absolue et relative. Si on veut pas toutes ces infos, il suffit d'ajouter l'option -silent à la commande.

En interne, les diffs sont recalculées à partir des 2 révisions que j'extrais à l'aide d'un pipe à partir d'une commande svn cat. Les numéros de révision à extraire sont récupérés à partir d'un svn log. Les fichiers peuvent donc être triés de manière différente et ça marche toujours.

Imaginons qu'on veuille maintenant comparer tous les CPUs sur toutes les machines:

stats.py -plot -silent sum apps\verif\CPU-*-All.txt

et hop! voilà le résultat:

On peut donc facilement comparer toutes les machines entre elles et, en particulier, identifier du premier coup d'oeil les commits de Pierre-Paul (quand la courbe “CYGWIN” rejoint celle de chinook).

Pour toutes ces courbes, le dernier point correspond à la révision sur votre disque. Elle prend donc en compte l'éventuelle batterie que vous avez lancée mais pas encore commitée.

Imaginons maintenant que vous vouliez voir plutôt l'évolution d'un cas-test au cours du temps. Pour cela, il faut utiliser la commande history au lieu de sum. Pour changer un peu, on ne va pas demander les CPUs mais plutôt l'évolution du nombre de pas de temps (STP) d'un test instable au cours des révisions (allez, tirGobin, au hasard, rien que pour rire):

stats.py -plot -silent history apps.exp.tirGobin apps\verif\STP-*-All.txt

La commande history demande le nom du module en plus des fichiers “verif”. On lance la commande et hop, voici le résultat:

Imaginons qu'on veuille maintenant exporter ces magnifiques gobineries sous excel… Pas de problème: il suffit de remplacer -plot par -txt et rediriger tout dans un fichier qu'on importera sous excel:

stats.py -txt -silent history apps.exp.tirGobin apps\verif\STP-*-All.txt > gobin.txt

où on n'a pas oublié le -silent sinon, la sortie contiendra aussi toutes les infos de parsing.

Et voilà tout ça sous excel:

Maintenant, il nous reste plus qu'à générer l'ancien fichier CPU en utilisant la commande details (au lieu de sum ou history) qui ne prend qu'un seul fichier à la fois pour des raisons évidentes de clarté:

stats.py -txt -silent details apps\verif\STP-OSF1-All.txt > cpus.txt

Ca ne marche, bien-sûr qu'en mode -txt.

Et voilà, une fois importé:

Il ne reste plus qu'à le mettre en forme si on veut le conserver ou tirer des courbes.

Pour la suite, je compte:

• Changer de lib pour les graphes (gnuplot, c'est laid…). J'utiliserai certainement matplotlib.
• Appeler le script à partir de battery.py pour insérer les statistiques du commit en cours dans le mail de résultat de batterie. Pour ça, il faudrait idéalement faire un export HTML.

Si vous avez des idées ou si vous trouvez des bugs, n'hésitez pas…

— Romain BOMAN 2007/08/07 17:24