Quel que soit le type d'application que vous développez, optimiser ses performances, vous assurer qu'elle se charge rapidement et qu'elle offre des interactions fluides est essentiel pour l'expérience utilisateur et le succès de l'application. Pour ce faire, vous pouvez inspecter l'activité d'une application à l'aide d'outils de profilage afin de voir ce qui se passe en coulisses pendant son exécution sur une période donnée. Le panneau "Performances" de DevTools est un excellent outil de profilage pour analyser et optimiser les performances des applications Web. Si votre application s'exécute dans Chrome, elle vous fournit une vue visuelle détaillée de ce que fait le navigateur pendant l'exécution de votre application. Comprendre cette activité peut vous aider à identifier des tendances, des goulots d'étranglement et des points chauds de performances sur lesquels vous pouvez agir pour améliorer les performances.
L'exemple suivant vous explique comment utiliser le panneau Performances.
Configurer et recréer notre scénario de profilage
Récemment, nous nous sommes fixés pour objectif de rendre le panneau Performances plus performant. En particulier, nous voulions qu'il charge plus rapidement de grands volumes de données sur les performances. C'est le cas, par exemple, lorsque vous effectuez le profilage de processus longs ou complexes, ou lorsque vous collectez des données à haute granularité. Pour ce faire, il a d'abord fallu comprendre comment l'application fonctionnait et pourquoi elle fonctionnait de cette manière. Pour ce faire, nous avons utilisé un outil de profilage.
Comme vous le savez peut-être, les outils pour les développeurs sont eux-mêmes une application Web. Il peut donc être profilé à l'aide du panneau Performances. Pour profiler ce panneau lui-même, vous pouvez ouvrir les outils pour les développeurs, puis une autre instance d'outils pour les développeurs qui y est associée. Chez Google, cette configuration est appelée DevTools-on-DevTools.
Une fois la configuration terminée, le scénario à profiler doit être recréé et enregistré. Pour éviter toute confusion, nous appellerons la fenêtre d'origine des outils pour les développeurs la première instance des outils pour les développeurs, et la fenêtre qui inspecte la première instance la deuxième instance des outils pour les développeurs.
Dans la deuxième instance DevTools, le panneau Performances (qui sera appelé panneau "perf" à partir de maintenant) observe la première instance DevTools pour recréer le scénario, qui charge un profil.
Dans la deuxième instance DevTools, un enregistrement en direct est lancé, tandis que dans la première instance, un profil est chargé à partir d'un fichier sur le disque. Un fichier volumineux est chargé afin de profiler précisément les performances du traitement de grandes entrées. Une fois le chargement des deux instances terminé, les données de profilage des performances (généralement appelées trace) s'affichent dans la deuxième instance DevTools du panneau "Performances" qui charge un profil.
État initial: identifier les possibilités d'amélioration
Une fois le chargement terminé, la capture d'écran suivante montre ce qui s'est passé avec notre deuxième instance de panneau de performances. Concentrez-vous sur l'activité du thread principal, qui est visible sous la piste intitulée Main (Principal). On peut voir qu'il existe cinq grands groupes d'activités dans le graphique en forme de flamme. Il s'agit des tâches pour lesquelles le chargement prend le plus de temps. La durée totale de ces tâches était d'environ 10 secondes. Dans la capture d'écran suivante, le panneau "Performances" permet de se concentrer sur chacun de ces groupes d'activités pour voir ce qui peut être trouvé.
Premier groupe d'activités: travail inutile
Il est apparu que le premier groupe d'activités était du code ancien qui s'exécutait toujours, mais qui n'était pas vraiment nécessaire. En gros, tout ce qui se trouve sous le bloc vert intitulé processThreadEvents était un effort inutile. Vous avez gagné rapidement. La suppression de cet appel de fonction a permis de gagner environ 1,5 seconde. C'est parfait !
Deuxième groupe d'activités
Dans le deuxième groupe d'activités, la solution n'était pas aussi simple que dans le premier. L'opération buildProfileCalls a pris environ 0,5 seconde, et cette tâche ne pouvait pas être évitée.
Par curiosité, nous avons activé l'option Mémoire dans le panneau des performances pour en savoir plus. Nous avons constaté que l'activité buildProfileCalls utilisait également beaucoup de mémoire. Vous pouvez voir ici que le graphique de la ligne bleue saute soudainement au moment de l'exécution de buildProfileCalls, ce qui suggère une fuite de mémoire potentielle.
Pour vérifier cette hypothèse, nous avons utilisé le panneau "Mémoire" (un autre panneau de DevTools, différent du panneau "Mémoire" du panneau "Performances"). Dans le panneau "Mémoire", le type de profilage "Échantillonnage d'allocation" a été sélectionné, ce qui a enregistré l'instantané du tas de mémoire pour le panneau "Performances" qui charge le profil CPU.
La capture d'écran suivante montre l'instantané de tas qui a été collecté.
À partir de cet instantané de tas, il a été observé que la classe Set consommait beaucoup de mémoire. Après vérification des points d'appel, nous avons constaté que nous attribuions inutilement des propriétés de type Set à des objets créés en grande quantité. Ce coût s'accumulait et une grande quantité de mémoire était consommée, au point que l'application plantait fréquemment en cas d'entrées volumineuses.
Les ensembles sont utiles pour stocker des éléments uniques et fournir des opérations qui exploitent l'unicité de leur contenu, comme la déduplication des ensembles de données et la fourniture de recherches plus efficaces. Cependant, ces fonctionnalités n'étaient pas nécessaires, car les données stockées étaient garanties comme étant uniques par rapport à la source. Par conséquent, les ensembles n'étaient pas nécessaires au départ. Pour améliorer l'allocation de mémoire, le type de propriété est passé d'un Set à un tableau simple. Après avoir appliqué cette modification, un autre instantané de tas a été effectué, et une allocation de mémoire réduite a été observée. Bien que cette modification n'ait pas permis d'améliorer considérablement la vitesse, elle a eu un autre avantage : l'application plantait moins fréquemment.
Troisième groupe d'activités: évaluer les compromis liés à la structure des données
La troisième section est particulière: vous pouvez voir dans le graphique de type "flamme" qu'elle se compose de colonnes étroites mais hautes, qui indiquent des appels de fonction profonds et des récursions profondes dans ce cas. Au total, cette section a duré environ 1,4 seconde. En examinant le bas de cette section, il est apparu que la largeur de ces colonnes était déterminée par la durée d'une fonction: appendEventAtLevel, ce qui suggérait qu'il pourrait s'agir d'un goulot d'étranglement.
Dans l'implémentation de la fonction appendEventAtLevel, une chose se démarque. Pour chaque entrée de données de l'entrée (appelée "événement" dans le code), un élément a été ajouté à une carte qui a suivi la position verticale des entrées de la chronologie. Cela posait problème, car le nombre d'éléments stockés était très important. Maps est rapide pour les recherches basées sur des clés, mais cet avantage n'est pas sans frais. À mesure qu'une carte devient plus volumineuse, ajouter des données peut devenir coûteux, par exemple en raison du hachage. Ce coût devient perceptible lorsque de grandes quantités d'éléments sont ajoutées à la carte successivement.
/**
* Adds an event to the flame chart data at a defined vertical level.
*/
function appendEventAtLevel (event, level) {
// ...
const index = data.length;
data.push(event);
this.indexForEventMap.set(event, index);
// ...
}
Nous avons testé une autre approche qui ne nous obligeait pas à ajouter un élément dans une carte pour chaque entrée du graphique en forme de flamme. L'amélioration a été significative, ce qui confirme que le goulot d'étranglement était bien lié aux frais généraux générés par l'ajout de toutes les données à la carte. La durée du groupe d'activités est passée d'environ 1,4 seconde à environ 200 millisecondes.
Avant :
Après :
Quatrième groupe d'activités: différer les tâches non critiques et les données de cache pour éviter les tâches en double
En faisant un zoom avant sur cette fenêtre, vous pouvez voir qu'il existe deux blocs d'appels de fonction presque identiques. En examinant le nom des fonctions appelées, vous pouvez déduire que ces blocs consistent en du code qui crée des arborescences (par exemple, avec des noms comme refreshTree ou buildChildren). En fait, c'est le code associé qui crée les vues d'arborescence dans le tiroir inférieur du panneau. Il est intéressant de noter que ces vues d'arborescence ne s'affichent pas immédiatement après le chargement. L'utilisateur doit plutôt sélectionner une vue arborescente (les onglets "De bas en haut", "Arborescence des appels" et "Journal des événements" dans le panneau) pour que les arborescences s'affichent. De plus, comme vous pouvez le constater sur la capture d'écran, le processus de création de l'arborescence a été exécuté deux fois.
Nous avons identifié deux problèmes avec cette image:
- Une tâche non critique freinait les performances du temps de chargement. Les utilisateurs n'ont pas toujours besoin de sa sortie. Par conséquent, la tâche n'est pas critique pour le chargement du profil.
- Le résultat de ces tâches n'a pas été mis en cache. C'est pourquoi les arbres ont été calculés deux fois, même si les données n'ont pas changé.
Nous avons commencé par différer le calcul de l'arborescence jusqu'à ce que l'utilisateur ouvre manuellement la vue arborescente. C'est seulement à ce moment-là que la création de ces arbres en vaut la peine. Le temps total d'exécution de cette opération deux fois était d'environ 3, 4 secondes.Le report a donc eu un impact significatif sur le temps de chargement. Nous étudions également la mise en cache de ces types de tâches.
Cinquième groupe d'activités: évitez les hiérarchies d'appels complexes si possible
En examinant attentivement ce groupe, il était clair qu'une chaîne d'appels particulière était appelée à plusieurs reprises. Le même schéma est apparu six fois à différents endroits du graphique en forme de flamme, et la durée totale de cette fenêtre était d'environ 2,4 secondes.
Le code associé appelé plusieurs fois est la partie qui traite les données à afficher sur le "mini-plan" (aperçu de l'activité de la chronologie en haut du panneau). Il n'était pas clair pourquoi cela se produisait plusieurs fois, mais cela n'aurait certainement pas dû se produire six fois. En fait, la sortie du code doit rester à jour si aucun autre profil n'est chargé. En théorie, le code ne doit s'exécuter qu'une seule fois.
Après examen, il s'est avéré que le code associé était appelé en raison de plusieurs parties du pipeline de chargement qui appelaient directement ou indirectement la fonction qui calcule la minicarte. En effet, la complexité du graphique des appels du programme a évolué au fil du temps, et d'autres dépendances ont été ajoutées à ce code à l'insu des développeurs. Il n'existe pas de solution rapide à ce problème. La solution dépend de l'architecture du codebase en question. Dans notre cas, nous avons dû réduire un peu la complexité de la hiérarchie des appels et ajouter une vérification pour empêcher l'exécution du code si les données d'entrée restent inchangées. Après avoir implémenté cette fonctionnalité, nous avons obtenu le calendrier suivant:
Notez que l'exécution du rendu de la minicarte se produit deux fois, et non une seule fois. En effet, deux minicartes sont dessinées pour chaque profil: une pour l'aperçu en haut du panneau et une pour le menu déroulant qui sélectionne le profil actuellement visible dans l'historique (chaque élément de ce menu contient un aperçu du profil qu'il sélectionne). Toutefois, ces deux éléments ont exactement le même contenu. L'un devrait donc pouvoir être réutilisé pour l'autre.
Étant donné que ces mini-cartes sont toutes deux des images dessinées sur un canevas, il a suffi d'utiliser l'utilitaire de canevas drawImage, puis d'exécuter le code une seule fois pour gagner du temps. La durée du groupe est ainsi passée de 2, 4 secondes à 140 millisecondes.
Conclusion
Après avoir appliqué toutes ces corrections (et quelques autres plus petites ici et là), le calendrier de chargement du profil a évolué comme suit:
Avant :
Après :
Le temps de chargement après les améliorations était de deux secondes, ce qui signifie qu'une amélioration d'environ 80% a été obtenue avec un effort relativement faible, car la plupart des corrections étaient rapides. Bien sûr, il était essentiel d'identifier correctement ce que faire au départ, et le panneau des performances était l'outil idéal pour cela.
Il est également important de souligner que ces chiffres sont propres à un profil utilisé comme sujet d'étude. Ce profil nous intéressait particulièrement, car il était particulièrement volumineux. Toutefois, comme le pipeline de traitement est le même pour chaque profil, l'amélioration significative obtenue s'applique à chaque profil chargé dans le panneau des performances.
Points à retenir
Ces résultats nous permettent de tirer quelques enseignements en termes d'optimisation des performances de votre application:
1. Utiliser des outils de profilage pour identifier les tendances de performances d'exécution
Les outils de profilage sont extrêmement utiles pour comprendre ce qui se passe dans votre application pendant son exécution, en particulier pour identifier les possibilités d'amélioration des performances. Le panneau "Performances" des outils pour les développeurs Chrome est une excellente option pour les applications Web, car il s'agit de l'outil de profilage Web natif du navigateur. Il est régulièrement mis à jour pour être à jour avec les dernières fonctionnalités de la plate-forme Web. De plus, il est désormais beaucoup plus rapide ! 😉
Utilisez des exemples qui peuvent être utilisés comme charges de travail représentatives et découvrez ce que vous pouvez trouver !
2. Éviter les hiérarchies d'appels complexes
Dans la mesure du possible, évitez de rendre votre graphique des appels trop compliqué. Avec des hiérarchies d'appels complexes, il est facile d'introduire des régressions de performances et difficile de comprendre pourquoi votre code s'exécute comme il le fait, ce qui rend difficile l'amélioration.
3. Identifier les tâches inutiles
Il est courant que les bases de code anciennes contiennent du code qui n'est plus nécessaire. Dans notre cas, le code ancien et inutile représentait une part importante du temps de chargement total. La suppression de cette fonctionnalité était la solution la plus simple.
4. Utiliser des structures de données de manière appropriée
Utilisez des structures de données pour optimiser les performances, mais tenez également compte des coûts et des compromis associés à chaque type de structure de données lorsque vous choisissez lesquelles utiliser. Il ne s'agit pas seulement de la complexité spatiale de la structure de données elle-même, mais aussi de la complexité temporelle des opérations applicables.
5. Mettre en cache les résultats pour éviter les tâches dupliquées pour les opérations complexes ou répétitives
Si l'exécution de l'opération est coûteuse, il est logique de stocker ses résultats pour la prochaine fois que vous en aurez besoin. Cela est également logique si l'opération est effectuée plusieurs fois, même si chaque fois n'est pas particulièrement coûteuse.
6. Reportez les tâches non critiques.
Si la sortie d'une tâche n'est pas nécessaire immédiatement et que l'exécution de la tâche prolonge le chemin critique, envisagez de la différer en l'appelant de manière paresseuse lorsque sa sortie est réellement nécessaire.
7. Utiliser des algorithmes efficaces pour de grandes entrées
Pour les entrées volumineuses, les algorithmes de complexité temporelle optimale deviennent cruciaux. Nous n'avons pas examiné cette catégorie dans cet exemple, mais son importance est difficile à exagérer.
8. Bonus: Comparer vos pipelines
Pour vous assurer que votre code en évolution reste rapide, il est judicieux de surveiller son comportement et de le comparer aux normes. Vous pouvez ainsi identifier de manière proactive les régressions et améliorer la fiabilité globale, ce qui vous permet de réussir sur le long terme.