TD 6 : Analyse de performances

PhilippeCollet

Introduction

Objectif

Dans ce TD, il s'agit d'expérimenter les principaux outils de monitoring disponibles dans le projet TPTP pour Eclipse :

• Mesures de temps d'exécution
• Analyse mémoire
• Analyse des threads

Point de départ

Prenez le projet résultant du TD sur l'héritage et faites en une copie. Pour éviter d'écrouler les machines surpuissantes dont vous disposez (!), réduisez le nombre de bébêtes créées à 10 au lieu de 200.

Observations

Temps d'exécution

Lancez le simulateur de bébêtes en mode profilage (bouton contenant une flèche verte avec une horloge en arrière-plan). La première fois, le panneau de configuration des profiles d'exécution va apparaître (Profile Configurations) et vous devez allez sélectionner le type de profilage dans l'onglet "Monitor". les fois suivantes, si vous rappuyez sur le bouton d'exécution, c'est cette configuration qui s'exécutera; lorsqu'il faudra changer les informations de profilage demandées, vous devrez aller de nouveau dans le panneau de config pour changer les paramètres (il suffit pour cela de déplier le menu sous le bouton d'exécution de profilage).

Laissez tourner l'application environ 60 secondes puis stoppez la. Dans la perspective de profilage (qu'Eclipse a du vous proposer par défaut), vous voyez apparaître à gauche la session d'exécution. Cliquez dessus avec le bouton droit et sélectionnez "Open With / Execution Statistics". Vous devriez voir apparaître un "Session summary" avec des temps par classes. Vous pouvez sélectionner la présentation de temps par package, classe ou méthode. Les colonnes sur les temps signifient :

• Base Time : le temps passé dans la méthode (dans son corps, pas dans le corps de méthodes appelées par celle-ci), cumulé sur toute la session d'exécution
• Average Base Time : le même temps, mais en moyenne par appel (en multipliant cette valeur par le nombre d'appels, vous devriez obtenir quelque chose de proche du Base Time
• Cumulative Time : le temps passé dans la méthode en tout (en comptant les appels à d'autres méthodes), cumulé sur la session

Allez ensuite observer les différents onglets inférieurs de cette vue : "call tree" vous permet de déplier le graphe d'appel (regardez AWT-event et Thread-3, ce sont nos deux principaux threads). Que pouvez-vous en déduire ?

A l'aide du "session summary" et du "call tree", et en utilisant le filtrage par méthode, trouvez :

• quelle(s) méthode(s) consomment le plus de temps total, de manière globale, puis par appel. Expliquez pourquoi.
• quelle(s) méthode(s) consomment le plus de temps propre (base), de manière globale, puis par appel. Expliquez pourquoi il y a des différences ou pas de différences avec l'analyse précédente.

Vérifiez votre analyse en demandant l'affichage du graphe d'appel (onglet inférieur : method invocation). Il faut sélectionner une méthode au préalable, puis une fois dans l'affichage, vous pouvez demander un détail plus poussé dans les appelants et les appelés (boutons dans la partie supérieure de la fenêtre). Vous observez à chaque fois un appel, vous pouvez aussi passer à l'invocation suivante, ceci est très intéressant quand il y a beaucoup de variations dans l'exécution de l'agorithme, comme dans getChosesVues()).

Posez vous ensuite la question de quelles méthodes sont les plus importantes à optimiser après cette première analyse.

Mémoire

Relancez une nouvelle session de profilage (changez la configuration d'exécution) en surveillant la mémoire. Ouvrez le résultat avec la vue "Object Allocations". Si rien ne s'affiche, c'est qu'il faut changer le filtrer en haut de la fenêtre et prendre par exemple "highest 10 total size". Cliquez ensuite sur une des classes et choisissez l'onglet inférieur "Allocation details" pour voir ou et quand les créations ont été faites. Vous pouvez par exemple tracer la création des BebetesEmergentes. Comme le simulateur ne se relance pas et qu'il ne crée par de nouvelles instances, ces informations sont peu pertinentes dans notre cas. Il s'agit juste d'expérimenter, l'analyse des threads va être plus intéressante...

Threads

Relancez une nouvelle session de profilage en demandant l'analyse des threads. Ouvrez le résultat avec la vue "Thread Analysis".

Dans le premier onglet "thread statistics", regardez quels threads ont été bloqués, cela peut varier en fonction de la rapidité de votre machine et du nombre de bébêtes affichées. Vous pouvez d'ailleurs remonter le nombre à 200 pour faire d'autres essais et voir la différence. Y-a-t-il une incidence sur les blocages et quel thread se trouve bloqué par quel autre ?

Dans l'onglet "monitor statistics", regardez quel thread passe beaucoup de temps à attendre ? Allez voir le code et expliquez pourquoi.

Le dernier onglet "Thread visualizer" est très utile, il permet de voir l'exécution des threads (vert = running, jaune = waiting, rouge = deadlocked !), on peut même faire afficher la pile d'appel de n'importe quel point dans le temps pour un thread donné. Il y a d'autres boutons en haut pour obtenir d'autres informations.

Au final, quelles expérimentations faudrait-il faire pour essayer de minimiser les deadlocks dans le simulateur ?

En dynamique...

Sachez que les observations faites précédemment peuvent aussi se faire dynamiquement, donc pendant que l'application tourne, et même à distance si tout est bien configuré. Si vos machines sont assez puissantes pour supporter ce mode, essayez de suivre dynamiquement le simulateur sur des aspects (temps, mémoire ou thread).

-- PhilippeCollet - 01 Dec 2009
to top