Vous pouvez regarder sous le capot du code ou consulter le CLR interne à l'aide de nombreux outils. Ce message est né d'un tweet , et je dois remercier tous ceux qui ont aidé à dresser une liste d'outils adaptés. Si j'ai raté l'un d'eux, écrivez dans les commentaires.
Tout d'abord, je dois mentionner qu'un bon débogueur est déjà présent dans Visual Studio et VSCode . Il existe également de nombreux bons profileurs .NET (commerciaux) et outils de surveillance des applications qui méritent d'être examinés. Par exemple, j'ai récemment essayé de travailler avec Codetrack et j'ai été impressionné par ses capacités.
Cependant, le poste restant est consacré aux outils pour effectuer des tâches individuelles , qui aideront à mieux comprendre ce qui se passe. Tous les outils sont open source .
PerfView est un excellent outil que j'utilise depuis plusieurs années. Il fonctionne sur la base du suivi des événements Windows (ETW) et vous permet de mieux comprendre ce qui se passe à l'intérieur du CLR, et donne également la possibilité d'obtenir un profil d'utilisation de la mémoire et du processeur. Pour maîtriser l'outil, vous devrez absorber beaucoup d'informations, par exemple à l'aide de vidéos de formation , mais cela en vaut la peine et l'effort.
L'outil est si utile que les ingénieurs de Microsoft l'utilisent eux-mêmes et de nombreuses améliorations récentes des performances de MSBuild sont apparues après l' analyse des goulots d'étranglement à l' aide de PerfView.
L'outil est basé sur la bibliothèque Microsoft.Diagnostics.Tracing.TraceEvent , que vous pouvez utiliser pour créer vos propres outils. De plus, puisque le code source de la bibliothèque est ouvert, grâce à la communauté, de nombreuses fonctions utiles y sont apparues, par exemple des graphiques de flamme :
SharpLab a émergé comme un outil pour vérifier le code IL généré par le compilateur Roslyn, et avec le temps, il a évolué vers quelque chose de plus :
SharpLab est un environnement interactif pour exécuter du code .NET, qui affiche les étapes intermédiaires et les résultats de la compilation du code. Certaines fonctions du langage ne sont que des wrappers pour d'autres, par exemple, l'utilisation de () devient try / catch. Avec SharpLab, vous verrez le code tel que le compilateur le voit et vous comprendrez mieux l'essence des langages .NET.
L'outil prend en charge C #, Visual Basic et F #, mais les fonctions les plus intéressantes sont la décompilation / désassemblage:
Les fonctions de décompilation / démontage peuvent être utilisées pour:
- C #
- Visual basic
- IL
- JIT Asm (code Asm natif)
Vous avez bien compris: l'outil génère le code assembleur que .NET JIT génère à partir de votre code C #:
Avec cet outil, vous pouvez analyser la structure des objets .NET en mémoire, c'est-à-dire comment JITter a organisé les champs appartenant à votre classe ou structure. Ceci est utile lors de l'écriture de code hautes performances. C'est aussi bien d'avoir un outil qui fait le travail dur pour nous.
Il n'y a pas de documentation officielle décrivant la structure du champ, car les auteurs du CLR se réservent le droit de la modifier à l'avenir. Mais la connaissance de la structure peut être utile si vous travaillez sur une application à haut débit.
Comment pouvez-vous étudier la structure? Vous pouvez consulter la mémoire brute dans Visual Studio ou utiliser la !dumpobj dans l' extension de débogage SOS . Les deux approches nécessitent beaucoup d'efforts, nous allons donc créer un outil qui affichera la structure de l'objet au moment de l'exécution.
Selon l'exemple du référentiel GitHub, si vous utilisez TypeLayout.Print<NotAlignedStruct>() avec un code similaire:
public struct NotAlignedStruct { public byte m_byte1; public int m_int; public byte m_byte2; public short m_short; }
La sortie suivante apparaîtra, qui montrera avec précision comment le CLR organisera la structure en mémoire en fonction des règles d'optimisation et de remplissage.
Size: 12. Paddings: 4 (%33 of empty space) |================================| | 0: Byte m_byte1 (1 byte) | |--------------------------------| | 1-3: padding (3 bytes) | |--------------------------------| | 4-7: Int32 m_int (4 bytes) | |--------------------------------| | 8: Byte m_byte2 (1 byte) | |--------------------------------| | 9: padding (1 byte) | |--------------------------------| | 10-11: Int16 m_short (2 bytes) | |================================|
Comme indiqué sur la page GitHub , TUNE est un outil prometteur. Il vous aidera à en savoir plus sur les composants internes .NET et à améliorer les performances en expérimentant le code C #.
Des informations détaillées sur lui peuvent être trouvées dans ce post , mais à un niveau élevé, elles fonctionnent comme suit :
- écrire un exemple de code C # fonctionnel qui contient au moins une classe avec une méthode publique qui accepte un paramètre de chaîne. Le code est lancé à l'aide du bouton Exécuter. Vous pouvez inclure un nombre illimité de méthodes et de classes. Mais rappelez-vous que la première méthode publique de la première classe publique sera exécutée en utilisant le premier paramètre de la fenêtre d'entrée sous le code;
- cliquez sur le bouton Exécuter pour compiler et exécuter le code. De plus, il sera compilé en code IL et code assembleur dans les onglets correspondants;
- pendant l'exécution de Tune (y compris à l'exécution), l'outil crée un graphique qui affiche les données du récupérateur de place. Il contient des informations sur les tailles de génération et les sessions de récupération de place (représentées par des lignes verticales avec un nombre ci-dessous, qui indique dans quelle génération la récupération de place est effectuée).
Cela ressemble à ceci:
Outils de diagnostic de mémoire CLR (ClrMD)
Enfin, examinons une certaine catégorie d'outils. Depuis la sortie de .NET, les développeurs ont toujours pu utiliser WinDBG et l' extension de débogage SOS pour voir ce qui se passe dans le runtime .NET. Cependant, ce ne sont pas les outils les plus faciles pour une première connaissance et, comme indiqué dans le prochain tweet, ils ne sont pas toujours les plus productifs:
Heureusement, Microsoft a rendu disponible la bibliothèque ClrMD (également connue sous le nom de Microsoft.Diagnostics.Runtime ), et maintenant n'importe qui peut créer un outil pour analyser les vidages de mémoire pour les programmes .NET. Des informations détaillées peuvent être trouvées sur le blog officiel . Je recommande également de jeter un œil à ClrMD.Extensions , qui "... fournit une intégration avec LINPad et rend l'utilisation de ClrMD encore plus facile . "
Je voulais dresser une liste de tous les outils existants et j'ai appelé Twitter pour obtenir de l'aide. Rappelez-vous: soyez prudent avec les tweets. Le responsable de WinDBG peut les lire et être contrarié!
La plupart de ces outils fonctionnent sur la base de ClrMD, car c'est le plus simple. Mais si vous le souhaitez, vous pouvez utiliser directement les interfaces COM . Il convient également de noter que tout outil basé sur ClrMD n'est pas multiplateforme , car ClrMD lui-même est conçu uniquement pour Windows. Les options multiplateformes sont décrites dans Analyse d'un vidage .NET Core Core sous Linux .
Enfin, afin de maintenir l'équilibre, une version améliorée de WinDBG est récemment apparue, qu'ils ont immédiatement essayé d'ajouter des fonctionnalités:
Après tous ces mots, passez à la liste:
- SuperDump ( GitHub )
- Outil d'analyse automatique de vidage sur incident ( présentation )
- msos ( github )
- Un environnement avec une interface de ligne de commande comme WinDbg pour exécuter des commandes SOS en l'absence de SOS.
- MemoScope.Net ( GitHub )
- Un outil pour analyser la mémoire de processus dans .NET. Vous pouvez vider la mémoire de l'application dans un fichier et le lire plus tard.
- Le fichier contient toutes les données (objets) et les informations sur les threads (état, pile, pile d'appels). MemoScope.Net analysera les données et vous aidera à trouver les fuites de mémoire et les blocages.
- dnSpy ( github )
- Débogueur et éditeur d'assembly .NET
- Il peut être utilisé pour éditer et déboguer des assemblys, même si vous n'avez pas de code source.
- MemAnalyzer ( GitHub )
- Un outil d'analyse de mémoire pour le code managé. Il existe une interface de ligne de commande.
- Comme
!DumpHeap dans !DumpHeap peut déterminer quels objets occupent le plus d'espace sur le tas sans avoir à installer un débogueur.
- DumpMiner ( GitHub )
- CLI de trace ( GitHub )
- Outil de débogage et de suivi pendant le fonctionnement
- Remise ( GitHub )
- Shed est une application qui analyse l'exécution d'un programme en .NET. Il peut être utilisé pour analyser les logiciels malveillants afin d'obtenir des données sur les informations stockées lors du lancement de ces logiciels. Le hangar peut:
- Récupérer tous les objets stockés dans le tas managé
- afficher les lignes stockées en mémoire;
- créer un instantané de segment de mémoire au format JSON pour un traitement ultérieur;
- vider tous les modules chargés en mémoire.
Vous pouvez trouver de nombreux autres outils qui utilisent ClrMD . Le rendre disponible était une bonne idée de Microsoft.
Autres outils
Autres outils à mentionner:
- Debugdiag
- L'outil DebugDiag est conçu pour résoudre les problèmes tels que les blocages, les performances médiocres, les fuites de mémoire ou la fragmentation, ainsi que les échecs des processus en mode utilisateur (désormais avec l'intégration CLRMD).
- SOSEX (peut-être plus en cours de développement)
- ... une extension pour le débogage du code managé qui réduit mon mécontentement avec SOS.
- VMMap de Sysinternals
