J'écris un plug-in pour un autre programme en C # .NET et que vous avez des problèmes de performance où les commandes prennent beaucoup plus longtemps, alors je le ferais. Le plug-in réagit aux événements dans le programme hôte et dépend également des méthodes utilitaires du programme hôte SDK. Mon plug-in a beaucoup de fonctions récursives parce que je fais beaucoup de lecture et d'écriture à une structure d'arbres. De plus, j'ai beaucoup d'abonnements d'événements entre mon plugin et l'application hôte, ainsi que des abonnements d'événements entre les classes de mon plug-in.
Comment puis-je comprendre ce qui prend si longtemps pour une tâche à compléter? Je ne peux pas utiliser de débogage de style de points d'arrêt régulier, car ce n'est pas que cela ne fonctionne pas que c'est juste que c'est trop lent. J'ai configuré une classe statique "logwriter" que je peux faire référence à partir de toutes mes classes qui me permettront d'écrire des lignes expressionnées à un fichier journal de mon code. Y a-t-il d'une autre manière? Visual Studio garde-t-il une sorte de journal horodaté que je pourrais utiliser à la place? Est-il possible de voir la pile d'appels après la fermeture de l'application?
8 Réponses :
On dirait que vous voulez un code "profileur". http://fr.wikipedia.org/wiki/code_profiler#use_of_profilers
Je ne suis pas familier avec quels profilers sont les meilleurs pour C #, mais je suis tombé sur ce lien après un rapide Google qui dispose d'une liste d'offres open-source gratuites. Je suis sûr que quelqu'un d'autre saura que ceux valent la peine d'être considérés comme :)
Vous devez utiliser le profileur. Ici, lien vers Good One: profileur de performance des fourmis .
Porte rouge Bien sûr faire de bons logiciels. Leur profileur de performance des fourmis est l'un des meilleurs à mon avis. Je crois que vous pouvez télécharger une version d'essai. La plupart des personnes qui achètent la version réelle ensuite, alors soyez averti :).
Eh bien, Microsoft Profiler est également bon, mais cela n'est inclus que dans des packs VS coûteux.
Thumbs up pour les fourmis de moi aussi, résolvé une énorme fuite de mémoire pour moi
@Simon Wilson, vous parlez d'autres fourmis - Profiler de mémoire :)
+1 sur le profileur des fourmis. Sérieusement. Vous trouverez votre goulot d'étranglement de performance avec cet outil. Vaut bien le coût du produit.
Merci pour toutes les réponses. Debug.Write semble le plus simple pour moi en ce moment. Je vais toujours vérifier DebugView cependant, les fonctionnalités de surbrillance devraient faire la lecture du journal beaucoup plus facile.
Malgré le titre de ce sujet, je dois faire valoir que la «meilleure» voie est subjective, nous ne pouvons que suggérer des solutions possibles.
J'ai eu de l'expérience en utilisant Redgate Profileur de performance des fourmis qui sera Montrez-vous où sont les goulots d'étranglement dans votre application. Il vaut vraiment la peine d'être vérifié.
N'oubliez jamais Le conseil de Rico Mariani sur la manière de procéder à une bonne enquête sur Perf.
Le lien est parti cassé ... peut-être https://medium.com/@ricomariumi/debugging-optimized-code-148 7649488A2 était ce qu'il faisait?
Le système d'équipe Visual Studio a un profileur au four, c'est loin d'être parfait, mais pour des applications simples, vous pouvez également le faire fonctionner.
Récemment, j'ai eu le plus de succès avec EQATECS Profileur libre, ou rouler mon propre minuscule classe de profilage où besoin.
En outre, il y a eu mal de nombreuses questions sur les profilers de ce passé voir: http://www.google.com.au/search?hl=fr&q=SiteHStacVoverflow.com+.net+profiler&btta= & aq = f & oq =
Vous pouvez également utiliser des compteurs de performance pour les applications ASP.NET.
Dans mon expérience, la meilleure méthode est également la plus simple. Obtenez-le en cours d'exécution et pendant qu'il est lent, appuyez sur le bouton "Pause" dans l'IDE. Ensuite, faites une trace de la pile d'appels. Répétez cela plusieurs fois. (voici un exemple plus détaillé et une explication.)
Ce que vous cherchez est une déclaration qui apparaît sur plusieurs échantillons de pile qui n'est pas strictement nécessaire. Plus il apparaît d'échantillons, plus il faut du temps. La façon de dire si la déclaration est nécessaire consiste à rechercher la pile, car cela vous dit pourquoi cela est fait.
Tout ce qui cause une quantité de temps importante à consommation sera révélé par cette méthode et la récursivité ne le dérange pas.
Les gens semblent aborder des problèmes comme celui-ci de deux manières:
Essayez d'obtenir de bonnes mesures avant de faire quoi que ce soit.
Il suffit de trouver quelque chose de gros que vous pouvez vous débarrasser, déchirer, et répéter.
Je préfère ce dernier, car c'est rapide, et parce que vous n'avez pas à connaître avec précision la taille de la tumeur de savoir qu'il est assez grand pour enlever. Ce que vous avez besoin de savoir est exactement là où il est, et c'est ce que cette méthode vous dit.