J'ai une application .NET et cela passe vite environ 2000 enregistrements qui commencent à aller vraiment lentement. J'essaie de trouver le goulot d'étranglement et je me demandais s'il y a un bien, éventuellement gratuit mais ce n'est pas obligé d'être, d'outil ou d'un moyen de trouver le goulot d'étranglement. J'essaie de trouver une liste qui n'est pas effacée mais je ne le vois pas encore. J'ai vs 2008.
4 Réponses :
Cette page de Adam Calderon Liens vers certaines pages de blogs MSDN sur le profilage.
Cependant, la plupart (sinon toutes) d'entre eux semblent être du système d'équipe Visual Studio. Donc, si vous avez accès à cette version du logiciel, vous obtenez des outils "gratuitement".
Si triste. Je viens de lire ( blogs.msdn.com/b/ianhu/archive/2007/09/14/... ) Si vous voulez être une entreprise de giga-dollar, vendez des gens ce qu'ils pensent ils veulent, pas ce qui fonctionne. Leur "hotpath" est basé sur l'idée que ce que vous recherchez est des endroits où la CPU dépense beaucoup de temps (points chauds ou endroits avec un coût exclusif élevé). Il ignore totalement les sites d'appels intermédiaires mal justifiés, et il est aveugle d'E / S. Ils devraient utiliser de vraies applications (beaucoup d'E / S de bas niveau, une grande structure de données). Mandelbrot est un jouet non représentatif.
Vous voudrez peut-être commencer à exécuter quelques Compteurs de performance pour surveiller l'utilisation des processeurs et les statistiques de la mémoire et déterminez ce qui se passe.
Si cela ne vous conduit pas à des réponses évidentes, il est temps de commencer à profilage.
Jetbrains DotTrace a un essai gratuit de 30 jours. C'est un profileur de mémoire et de performance assez décent que vous pourriez vouloir vérifier.
's Profiler CLR est gratuit.
Si vous n'aurez toujours rien, il est temps de sortir des grandes armes: WINDBG . Si vous obtenez aussi loin, vous trouverez Tess 'Blog extrêmement utile.
+1 bonnes références. .NET Framework 4 profileur
devpartner pour C ++ Mon microfocus (anciennement COMPUWARE) a un profileur de performance qui était à mi-chemin décent. Intel rend V-Tune qui fait la même chose. (Je pense que c'est Intel ... Je ne l'ai jamais utilisé). Mon préféré est celui qui est livré avec Visual Studio Team Edition. C'est bien. Vous devez également instruminer votre propre code et écrire également des tests automatisés afin que vous puissiez comparer une construction à la suivante.
Il y a un très bon outil gratuit et vous l'avez déjà. Ce n'est que l'inconvénient, c'est que cela ne soit peut-être pas intuitif, de commencer.
Lorsque le programme agit lentement, mettez-le en pause sous l'IDE. Examinez la pile d'appels. (J'éteins l'affichage des arguments; Je ne suis intéressé que par les lignes spécifiques du code. Je copie tout l'empilement sur un éditeur de texte, comme le Bloc-notes.) Faites-le plusieurs fois. Plus il est plus lent, les moins d'échantillons dont vous aurez besoin avant de voir le problème.
Si vous voyez une ou plusieurs déclarations qui sont suspectement populaires, comme elles apparaissent sur une fraction saine d'échantillons (au moins deux), vous devez faire attention à ceux-ci. Ce que je fais, c'est prendre quelques échantillons de plus jusqu'à ce qu'ils se présentent, car je veux comprendre pourquoi ils sont exécutés. C'est important, car si je pouvais les remplacer par quelque chose qui a pris beaucoup moins de temps, je sauverais une grande fraction.
Je vais essayer d'expliquer pourquoi ça marche.
Premièrement, le concept commun du "goulot d'étranglement" est sérieusement trompeur.
Le logiciel n'est pas lent car il a des constrictions ou des lieux "chauds".
Bien sûr, il peut avoir des caches manquées et ainsi de suite, mais la raison dominante
Il est lent, c'est que cela fait plus qu'il n'a besoin de - souvent un lot plus.
Il s'éteint sur une fonction imbriquée des appels d'appels,
avec des justifications de plus en plus éloignées.
Cela se présente comme un arbre d'appels qui est beaucoup plus touffu que nécessaire.
Tout ce que vous avez à faire est de trouver de grandes branches que vous pouvez tailler.
C'est ce que fait la technique de pause.
Donc, alors que vous cherchez à l'outil qui vous aidera à jouer à un détective pour localiser le "goulot d'étranglement" insaisissable, être chirurgien de l'arbre et élaguer les branches les plus lourdes que vous pouvez de l'arborescence, comme l'a été constatée en pause et Continuez à le faire jusqu'à ce que vous ne puissiez pas.
Il est bon d'être sceptique, mais vous pouvez être surpris de savoir à quel point cela fonctionne bien.
Ou, vous pouvez simplement utiliser un profileur qui enregistrera vos appels pour chaque fil avec beaucoup de statistiques utiles que vous ne recevrez pas de l'IDE.
@Winston: Ne pas discuter, mais cela n'enregistrera pas vos arbres d'appels (c'est impossible) et cela vous donne beaucoup de statistiques, mais ils font généralement pas vous pointez sur les problèmes. Les meilleurs profileurs (OMI) sont tels que zoom, qui échantillonnent des piles d'appel (sur le temps de l'horloge murale) et vous indiquent la ligne (non par fonction)% des échantillons de pile contenant la ligne. "Heure de soi", les comptes d'appel, la durée moyenne des appels, sont des statistiques communes et sont inutiles, de même que les graphes d'appel: Stackoverflow.com/Questtions/1777556/alternatives-a-gProf/.../a>
Vous voudrez peut-être jeter un coup d'œil à Windbg et SOS - windbg.dumpanalysis.org Vous pouvez prendre une mémoire de mémoire de l'application quand il ralentit et l'analyser pour des ressources inédites
Y a-t-il un code que vous pouvez poster?
Essayez certaines des étapes détaillées dans cette question que j'ai répondue précédemment: Profilage et optimisation
Quelle édition de Visual Studio avez-vous? Dans VS2008 DÉVELOPPEMENT / SUITE EDITIONS, il existe un profileur intégré pour le code natif et géré (Divulgation: Je suis sur l'équipe qui l'a construite).