Mesurer les performances des applications en analysant l’utilisation du processeur (C#, Visual Basic, C++, F#)

Recherchez les problèmes de performances pendant le débogage avec l’outil de diagnostic Utilisation de l’UC intégré au débogueur. Vous pouvez également analyser l’utilisation du processeur sans débogueur attaché ou en ciblant une application en cours d’exécution. Pour plus d’informations, consultez Utiliser des outils de profilage sur les builds de mise en production ou de débogage et Analyser les performances à l’aide du profilage du processeur.

Lorsque le débogueur s’interrompt, l’outil utilisation du processeur dans la fenêtre Outils de diagnostic collecte des informations sur les fonctions qui s’exécutent dans votre application. L’outil répertorie les fonctions qui effectuaient des travaux et fournit un graphique de chronologie que vous pouvez utiliser pour vous concentrer sur des segments spécifiques de la session d’échantillonnage.

Important

Les outils de diagnostic intégrés au débogueur sont pris en charge pour le développement .NET dans Visual Studio, notamment ASP.NET, ASP.NET Core et pour le développement natif/C++. La charge de travail Visual Studio correspondante est nécessaire. Windows 8 et les versions ultérieures sont nécessaires pour exécuter les Outils de profilage avec le débogueur (fenêtre Outils de diagnostic).

Dans ce tutoriel, vous allez :

• Collecter les données d’utilisation du processeur
• Analyser les données d’utilisation du processeur

Étape 1 : Collecter les données d’utilisation du processeur

1. Ouvrez le projet que vous souhaitez déboguer dans Visual Studio et définissez un point d’arrêt dans votre application au moment où vous souhaitez examiner l’utilisation du processeur.

2. Définissez un deuxième point d’arrêt à la fin de la fonction ou de la région de code que vous souhaitez analyser.

   En définissant deux points d’arrêt, vous pouvez limiter la collecte de données aux parties du code que vous souhaitez analyser.

3. La fenêtre Outils de diagnostic s’affiche automatiquement, sauf si vous l’avez désactivée. Pour réafficher la fenêtre, cliquez sur Déboguer>Fenêtres>Afficher les Outils de diagnostic.

4. Vous pouvez choisir de voir Utilisation du processeur , Utilisation de la mémoire , ou les deux, avec le paramètre Sélectionner outils dans la barre d’outils. Si vous exécutez Visual Studio Enterprise, vous pouvez également activer ou désactiver IntelliTrace dans Tools>Options>IntelliTrace.

   

   Nous examinerons principalement l'utilisation du processeur, alors assurez-vous que Utilisation du processeur est activée (elle est activée par défaut).

5. Cliquez sur Déboguer>Démarrer le débogage (ou Démarrer dans la barre d’outils ou F5).

   Une fois le chargement terminé, l’affichage Résumé des outils de diagnostic s’affiche. Pour ouvrir la fenêtre, cliquez sur Déboguer>Fenêtres>Afficher les Outils de diagnostic.

   capture d’écran

   Pour plus d’informations sur les événements, consultez recherche et filtrage de l’onglet Événements de la fenêtre Outils de diagnostic.

6. Exécutez le scénario qui doit provoquer le premier point d’arrêt.

7. Pendant que le débogueur est suspendu, activez la collecte des données d’utilisation du processeur, puis ouvrez l’onglet Utilisation du processeur.

   

   Lorsque vous choisissez Record CPU Profile, Visual Studio commence à enregistrer vos fonctions et combien de temps ils prennent pour s’exécuter. Vous ne pouvez afficher ces données collectées que lorsque votre application est arrêtée à un point d’arrêt.

8. Appuyez sur F5 pour exécuter l'application jusqu'à votre deuxième point d'arrêt.

   À présent, vous disposez maintenant de données de performances pour votre application spécifiquement pour la région du code qui s’exécute entre les deux points d’arrêt.

   Le profileur commence la préparation des données du thread. Attendez qu’elle se termine.

   

   L’outil Utilisation de l’UC affiche le rapport sous l’onglet Utilisation de l’UC.

   capture d’écran

9. Si vous souhaitez sélectionner une région de code plus spécifique à analyser, sélectionnez une région dans la chronologie du processeur (il doit s’agir d’une région qui affiche les données de profilage).

   

   À ce stade, vous pouvez commencer à analyser les données. Si vous rencontrez des problèmes lors de la collecte ou de l’affichage de données, consultez Résoudre les erreurs de profilage et résoudre les problèmes.

   Conseil

   Lorsque vous essayez d’identifier les problèmes de performances, prenez plusieurs mesures. Les performances varient naturellement de l’exécution à l’exécution, et les chemins de code s’exécutent généralement plus lent la première fois qu’ils s’exécutent en raison d’un travail d’initialisation unique, comme le chargement de DLL, les méthodes de compilation JIT et l’initialisation des caches. En prenant plusieurs mesures, vous obtenez une meilleure idée de la plage et de la médiane de la métrique affichée, ce qui vous permet de comparer la première fois par rapport aux performances d’état stable d’une zone de code.

Étape 2 : Analyser les données d’utilisation du processeur

Nous vous recommandons de commencer à analyser vos données en examinant la liste des fonctions sous Utilisation du processeur, en identifiant les fonctions qui effectuent le plus de travail, puis en examinant de plus près chacune d’elles.

1. Dans la liste des fonctions, examinez les fonctions qui effectuent le plus de travail.

   

   Conseil

   Les fonctions sont répertoriées dans l’ordre en commençant par celles qui effectuent le plus de travail (elles ne sont pas dans l’ordre des appels). Cela vous permet d’identifier rapidement les fonctions les plus longues en cours d’exécution.

2. Dans la liste des fonctions, double-cliquez sur l’une de vos fonctions d’application qui effectuent beaucoup de travail.

   Lorsque vous double-cliquez sur une fonction, la vue Functions s’ouvre dans le volet gauche. Sélectionnez la vue Appelant/appelé dans le menu déroulant.

   

   Dans cette vue, la fonction sélectionnée apparaît dans l’en-tête et dans la zone fonction actuelle (DoWork, dans cet exemple). La fonction qui a appelé la fonction active s’affiche sur la gauche sous Fonctions appelantes, et toutes les fonctions appelées par la fonction active s’affichent dans la zone Fonctions appelées sur la droite. (Vous pouvez sélectionner l’une ou l’autre zone pour modifier la fonction actuelle.)

   Cette vue vous montre le temps total (ms) et le pourcentage du temps d’exécution de l’application globale que la fonction a pris pour terminer. La section Corps de la fonction montre également la durée totale (et le pourcentage correspondant) passée dans le corps de la fonction, à l’exclusion du temps passé dans les fonctions appelantes et appelées.

   Conseil

   Des valeurs élevées dans le corps de la fonction peuvent indiquer un goulot d’étranglement de performances au sein de la fonction.

3. Pour afficher une vue de niveau supérieur montrant l'ordre dans lequel les fonctions sont appelées, sélectionnez l'arborescence des appels dans la liste déroulante en haut du volet.

   Chaque zone numérotée de la figure est liée à une étape de la procédure.

   

   Image	Description
   	Nœud de niveau supérieur dans l’arborescence des appels d’utilisation du processeur, représentant l’application.
   	Dans la plupart des applications, lorsque l’option Afficher le code externe est désactivée, le nœud de deuxième niveau est un nœud [Code externe] qui contient le code système et le code d’infrastructure qui démarre et arrête l’application, dessine l’interface utilisateur, contrôle la planification des threads et fournit d’autres services de bas niveau à l’application.
   	Les enfants du nœud de deuxième niveau sont les méthodes de code utilisateur et les routines asynchrones appelées ou créées par le système de deuxième niveau et le code d’infrastructure.
   	Les nœuds enfants d'une méthode contiennent des données seulement pour les appels de la méthode parente. Lorsque l'option Afficher le code externe est désactivée, les méthodes d'app peuvent également contenir un nœud [Code externe].

   Voici plus d’informations sur les valeurs de colonne :

   • La section Total UC (ms) indique la quantité de travail effectué par la fonction et toute autre fonction appelée par celle-ci. Les valeurs de processeur totales élevées pointent vers les fonctions qui sont les plus coûteuses dans l’ensemble.

   • La colonne Processeur auto (ms) indique la quantité de travail effectué par le code dans le corps de la fonction, à l’exception du travail effectué par les fonctions appelées par celle-ci. Des valeurs élevées dans la colonne Processeur auto (ms) peuvent indiquer un goulot d’étranglement des performances au sein de la fonction.

   • Modules Le nom du module contenant la fonction ou le nombre de modules contenant les fonctions dans un nœud [Code externe].

   Pour afficher les appels de fonction qui présentent le taux d’UC le plus élevé dans la vue Arborescence des appels, cliquez sur Développer le chemin chaud. Le chemin chaud peut vous aider à concentrer votre enquête sur la zone susceptible d’avoir le plus d’impact.

   

   Remarque

   Si vous voyez du code dans l’arborescence des appels marqués comme du code « interrompu » ou « pile intraitable », cela signifie que les événements de suivi d’événements pour Windows (ETW) ont probablement été supprimés. Essayez de collecter la même trace une deuxième fois pour résoudre le problème.

4. Pour afficher une autre vue des données, sélectionnez Flame Graph dans la liste déroulante en haut du volet.

   Le graphique de flammes fournit une visualisation différente de l’arborescence des appels qui peut vous aider à analyser les données. Pour plus d’informations, consultez Identifier les chemins chauds avec un graphique en flamme.

Afficher le code externe

Le code externe est des fonctions dans les composants système et framework qui sont exécutés par le code que vous écrivez. Le code externe inclut des fonctions qui démarrent et arrêtent l’application, dessinent l’interface utilisateur, contrôlent le threading et fournissent d’autres services de bas niveau à l’application. Dans la plupart des cas, vous ne serez pas intéressé par le code externe. Par conséquent, l’outil Utilisation du processeur rassemble les fonctions externes d’une méthode utilisateur dans un nœud [Appel externe].

Si vous souhaitez afficher les chemins d’appel du code externe, désélectionnez Afficher Uniquement mon code dans la liste Paramètres, puis choisissez Appliquer.

N’oubliez pas que de nombreuses chaînes d’appels de code externe sont profondément imbriquées, afin que la largeur de la colonne Nom de la fonction puisse dépasser la largeur d’affichage de tous les moniteurs d’ordinateur, mais les plus grands. Lorsque cela se produit, les noms de fonction sont affichés comme [...].

Utilisez la zone de recherche pour rechercher un nœud que vous recherchez, puis utilisez la barre de défilement horizontale pour afficher les données.

Conseil

Si vous profilez du code externe qui appelle des fonctions Windows, vous devez vérifier que vous disposez des fichiers .pdb les plus récents. Sans ces fichiers, vos vues de rapport répertorient les noms de fonctions Windows qui sont cryptiques et difficiles à comprendre. Pour vérifier si vous disposez des fichiers nécessaires, consultez Spécifier des fichiers de symboles (.pdb) et des fichiers sources dans le débogueur.

Étapes suivantes

Dans ce tutoriel, vous avez appris à collecter et analyser les données d’utilisation du processeur. Si vous avez déjà effectué la visite guidée du profileur, vous pouvez passer par un didacticiel qui montre comment utiliser les outils plus efficacement.

Étude de cas : guide du débutant pour optimiser le code de

Dans ce tutoriel, vous avez appris à collecter et analyser les données d’utilisation du processeur lors du débogage. Vous souhaiterez peut-être en savoir plus sur l'analyse des compilations en production à l'aide du Profileur de performances.

Analyser l’utilisation du processeur dans l’outil de profilage des performances