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.
Quand le débogueur est en pause, l’outil Utilisation du processeur de la fenêtre Outils de diagnostic collecte des informations sur les fonctions qui s’exécutent dans votre application. L’outil liste les fonctions qui ont effectué un certain travail et fournit un graphique chronologique que vous pouvez utiliser pour examiner des segments spécifiques d’une 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, y compris 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
Ouvrez le projet que vous voulez déboguer dans Visual Studio, puis définissez un point d’arrêt dans votre application à l’endroit où vous voulez examiner l’utilisation du processeur.
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 limitez la collecte de données aux sections de code que vous souhaitez analyser.
La fenêtre Outils de diagnostic apparaît 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.
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 Outils>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).
Cliquez sur Déboguer>Démarrer le débogage (ou Démarrer dans la barre d’outils ou F5).
Quand l’application est chargée, la vue Résumé des outils de diagnostics s’affiche. Si vous devez ouvrir la fenêtre, cliquez sur Déboguer>Fenêtres>Afficher les Outils de diagnostic.
capture d’écran
capture d’écran
Pour plus d’informations sur les événements, consultez Recherche et filtrage dans l’onglet Événements de la fenêtre Outils de diagnostic.
Exécutez le scénario qui doit provoquer le premier point d’arrêt.
Pendant que le débogueur est en pause, activez la collecte des données d’utilisation du processeur, puis ouvrez l’onglet Utilisation du processeur.
Quand vous choisissez Enregistrer le profil du processeur, Visual Studio commence à enregistrer vos fonctions et leur durée d’exécution. Vous pouvez voir ces données collectées seulement quand votre application s’interrompt à un point d’arrêt.
Appuyez sur F5 pour exécuter l'application jusqu'à votre deuxième point d'arrêt.
Vous disposez maintenant de données de performances pour votre application, plus spécifiquement pour la partie du code qui s’exécute entre les deux points d’arrêt.
Le profileur commence la préparation des données des threads. Attendez qu’elle se termine.
L’outil Utilisation de l’UC affiche le rapport sous l’onglet Utilisation de l’UC.
capture d’écran
capture d’écran
Si vous voulez analyser une partie plus spécifique du code, sélectionnez une partie dans la chronologie du processeur (il doit s’agir d’une partie qui montre des 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 des données, consultez Résoudre les erreurs de profilage et corriger les problèmes.
Conseil
Quand vous essayez d’identifier les problèmes de performances, prenez plusieurs mesures. Les performances varient naturellement d’une exécution à l’autre, et les chemins de code s’exécutent généralement plus lentement la première fois en raison d’un travail d’initialisation qui est effectué une seule fois, comme le chargement des 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 les performances de l’état stable d’une partie de code par rapport à sa première exécution.
É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 située sous l’onglet Utilisation du processeur, d’identifier les fonctions qui effectuent la plus grande partie du travail, puis d’analyser plus en détail ces fonctions les unes après les autres.
Dans la liste des fonctions, examinez celles qui effectuent le plus de travail.
Conseil
Les fonctions sont classées par ordre, en commençant par celles qui effectuent le plus de travail (elles ne sont pas classées selon leur ordre d’appel). Ainsi, vous pouvez identifier rapidement les fonctions avec les temps d’exécution les plus longs.
Dans la liste des fonctions, double-cliquez sur une des fonctions d’application qui effectuent un grande quantité de travail.
Quand vous double-cliquez sur une fonction, la vue Fonctions 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 s’affiche dans le titre et dans la zone Fonction actuelle (dans cet exemple, DoWork). 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 de ces zones pour changer la fonction active.)
Cette vue montre la durée totale (en ms) et le pourcentage du temps global d’exécution de l’application nécessaires à l’exécution de la fonction. 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.
Quand vous double-cliquez sur une fonction, la vue Appelant/appelé s’ouvre dans le volet gauche.
Dans cette perspective, la fonction sélectionnée apparaît dans l'en-tête et dans la zone fonction actuelle (GetNumber, 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 de ces zones pour changer la fonction active.)
Cette vue montre la durée totale (en ms) et le pourcentage du temps global d’exécution de l’application nécessaires à l’exécution de la fonction. 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. (Dans cet exemple, 2 367 ms sur 2 389 ont été passées dans le corps de la fonction, et les 22 ms restantes ont été passées dans le code externe appelé par cette fonction.)
Conseil
Des valeurs élevées dans Corps de la fonction peuvent indiquer un goulot d’étranglement des performances au sein de la fonction elle-même.
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 dans la figure se rapporte à une étape de la procédure.
Image Description 
Le nœud de plus haut niveau dans l’arborescence des appels de l’utilisation du processeur, représentant l’application. 
Dans la plupart des applications, quand l’option Afficher le code externe est désactivée, le nœud de deuxième niveau est un nœud [Code externe] contenant le code du système et du framework 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 du code utilisateur et des routines asynchrones appelées ou créées par le code du système et du framework de deuxième niveau. 
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 davantage d’informations sur les valeurs des colonnes :
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 reflétant une utilisation totale élevée du processeur indiquent les fonctions qui sont globalement les plus coûteuses.
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 en collectant la même trace une deuxième fois pour résoudre le problème.
Pour afficher une autre vue des données, sélectionnez Graphique en flamme dans la liste déroulante en haut du volet.
Le graphique en flamme 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.
Pour afficher les vues des données agrégées par fonction ou par module, sélectionnez Functions ou Modules dans la liste déroulante en haut du volet.
Ces vues permettent d’identifier les fonctions ou modules susceptibles d’être des goulots d’étranglement des performances en raison d’une combinaison de nombres d’appels élevés et/ou de problèmes de performances.
Voir le code externe
Le code externe correspond aux fonctions des composants du système et du framework qui sont exécutées par le code que vous écrivez. Le code externe comprend des fonctions qui démarrent et arrêtent l’application, dessinent l’interface utilisateur, contrôlent les threads et fournissent d’autres services de bas niveau à l’application. Dans la plupart des cas, vous n’êtes pas intéressé par le code externe : l’outil Utilisation du processeur regroupe donc les fonctions externes d’une méthode utilisateur dans un même nœud [Appel externe].
Si vous voulez voir afficher les chemins d’appel du code externe, désélectionnez Afficher Uniquement mon code dans la liste Paramètres, puis choisissez Appliquer.
Le code externe correspond aux fonctions des composants du système et du framework qui sont exécutées par le code que vous écrivez. Le code externe comprend des fonctions qui démarrent et arrêtent l’application, dessinent l’interface utilisateur, contrôlent les threads et fournissent d’autres services de bas niveau à l’application. Dans la plupart des cas, vous n’êtes pas intéressé par le code externe : l’outil Utilisation du processeur regroupe donc les fonctions externes d’une méthode utilisateur dans un même nœud [Code externe].
Si vous voulez afficher les chemins d’appel du code externe, choisissez Afficher le code externe dans la liste Filtrer la vue, puis Appliquer.
N’oubliez pas que de nombreuses chaînes d’appels du code externe sont imbriquées profondément, de sorte que la largeur de la colonne Nom de fonction peut excéder la largeur d’affichage de tous les écrans d’ordinateur sauf les plus grands. Si tel est le cas, les noms de fonction sont affichés sous forme de […].
Utilisez la zone de recherche pour trouver le nœud que vous cherchez, puis utilisez la barre de défilement horizontal pour faire apparaître 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, les vues de votre rapport vont lister des noms de fonctions Windows énigmatiques 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 découvert comment collecter et analyser les données d’utilisation du processeur. Si vous avez déjà effectué la visite guidée du profileur, vous pouvez suivre un tutoriel qui montre comment utiliser les outils plus efficacement.
Dans ce tutoriel, vous avez découvert comment collecter et analyser les données d’utilisation du processeur pendant le débogage. Vous souhaiterez peut-être en savoir plus sur l'analyse des compilations en production à l'aide du Profileur de performances.