//Build/ 2012: Retour sur la session “Diagnosing performance and memory issues in Javascript based Windows Store Apps”
Cette Session était centrée sur les outils proposés par Visual Studio pour le diagnostic de nos applications Windows Store en JavaScript. Le speaker est Andrew Hall, membre de l’équipe de développement des outils de profiling de Visual Studio 2012.
Dans ce billet, je vais revenir sur les outils présentés dans cette session de façon synthétique. Je reviendrai dessus plus en détail dans des prochains billets de blog.
Au programme:
- Bonnes pratiques pour les perfs
- Visual Studio Profiler
- HTML5 Performance Analyser
- Profileur mémoire Javascript
Pré-requis: Pour utiliser les outils présentés dans la session, il faut récupérer le Quarter Update #1 de Visual Studio 2012 en vous rendant sur http://www.microsoft.com/fr-fr/download/details.aspx?id=34818
Bonnes pratiques
=> Ne pas bloquer le thread de rendu de l’interface graphique!
=> Les délais au dela de 100ms sont remarqués par les utilisateurs
=> Découper les grosses opérations ou utiliser des web workers
=> surveiller la mémoire utilisée par l'app: Plus légere sera l'app, moins de chance elle aura de planter
=> Tenter d’améliorer les perfs de l'app régulièrement
Visual Studio 2012 Javascript profiler
Le profiling génère une rapport qui fourni:
- Le temps d'exec de chaque methode
- Le nombre exact total d'appels a chaque methode
Les metriques ne montrent queles temps d’exécution du code Javascript et pas le temps des autres services (rendering, layout, etc…)
Le vocabulaire du profiler Javascript:
=> inclsuive time: temps total d’exécution, comprenant les fonctions enfants
=> exclusive time: temps total d’exécution, ne comprenant pas le temps des fonctions enfants
Comment utiliser le profiler JS:
Menu Debug>Start performance Analysis ou Start performance Analysis Paused
La version “Paused” permet de ne pas lancer immédiatelment le profiling. Il suffit d’utiliser son app, puis quand on veut démarrer le profiling, il suffit de bascule dans Visual Studio et de cliquer sur Start profiler
Ensuite, exécutez les actions que vous souaitez analyser, puis faites Stop profiling pour génrer le rapport des infos enregistrées.
Dans le rapport (fichier *.vspx), on trouve notamment les infos suivantes:
- Le HOT PATH est l'arbre des méthodes les plus gourmandes (avec le % de temps d'exec sur le total)
- les Functions with most individual work
- le Call tree wiew: contient les détails du temps, du nombre exact d'appels etc… pour chaque methode!
On peut alors parcourir le detail d'exec des méthodes et voir les metrics. Il suffit de modifier le code qui est lent pour tenter de l’optimiser on rerun et de comparer les resultats avec le précédent profiling.
HTML5 performance analyzer
Cet outil est installé avec le SDK Win8. Il génère un rapport qui mesure 13 points clés de perfs:
- Les temps d’activation
- Le temps de réponse de l’UI
- Le nombre d’appels au process de Layout
- Les requetes synchones XMLHttpRequest sur le thread UI
- Les redimensionnements d’image
- L’empreinte mémoire
- Les sets de références mémoire bloquant le Runtime
- Les fuites mémoires
- L’état Idle du CPU
- Les phases d’attente
- Les réduction de l’occupation mémoire pendant les phases d’attente
- La croissance de l’occupation mémoire de l’app
- Les pics d’occupation mémoire bloquants pour le Runtime
Utilisation du HTML5 performance analyser
Lancer le programme et sélectionner l'app dans la liste puis suivre les instructions données par l'analyser:
- Lancer et utiliser l'app qques minutes et tourner le device dans tous les sens, on teste le snap… etc…
- Le programme analyse les perfs et génère le rapport
Le rapport généré est un fichier HTML qui liste les resultats des fonctionnalités testées. Il y a 3 états possible: PASSED, WARNING et FAILED. Les warning et failed fournissent des details sur le problème et comment le fixer.
Les failed sont des points qui sont sensibles au niveau des perfs et doivent etre fixés pour assurer des bonnes performances.
Javascript memory Profiler
Cet outil permet d’identifier les espaces mémoires retenus de façon non intentionnelle. Il se base sur des snapshots de l'état du Heap Javascript à un moment donné.
Les informations proposés dans nos snapshots montrent les éléments JS et DOM:
- Taille de l’objet en mémoire
- Nombre d’instances de l’objet
- Graph des références (appels et référence à l'element dans le projet)
Le vocabulaire du profileur mémoire:
- Size: taille de l’object en memoire (son instance à lui, sans les instance liée)
- Retained size: la qtité de memoire de l'objet dans le garbage collector = quantité de mémoire libérée si on supprime l’objet (son instance + d’éventuelles insatnce liées qui seront supprimées avec elle)
Utilisation du profileur mémoire:
Lancer le profileur mémoire javascript: dans le ménu DEBUG > launch Javascript Memory Analysis et choisir l'app (package) installé.
On execute l'application et on prend des snapshots au moments de certaines actions clés pour analyser la charge mémoire pour les éléments du DOM et du Javascript.
Avec plusieurs snapshots, on peut alors voir les évolutions entre deux snapshots et remonter jusqu'à la source du problème.
Encore un fois, je vous proposerai très rapidement des articles plus détaillés sur l’utilisation de ces nouveaux outils très prometteurs!
A très bientôt!!
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
