Mise au point par rapport à la performance de sortie

Question

Je l'ai rencontré le paragraphe suivant:

« Debug vs valeur Release IDE lorsque vous compilez votre code dans Visual Studio fait presque pas de différence à la performance ... le code généré est presque la même. Le compilateur C# ne fait vraiment aucune optimisation. Le compilateur C# crache juste IL ... et à l'exécution c'est le JITer qui fait toute l'optimisation. Le JITer possède un mode Debug/Release et cela fait une énorme différence en termes de performances. Mais cela ne met pas hors si vous exécutez la configuration Debug ou Release de votre projet, que les clés hors si un débogueur est attaché. »

La source est here et le podcast est here. Est-ce que quelqu'un peut me diriger vers un article de Microsoft qui peut réellement le prouver?

googler "C# debug vs performances de libération" la plupart renvoie les résultats disant "Debug a beaucoup de performance due", "version est optimisé" et "ne déployons pas debug à la production" .

Answer 1

Partiellement vrai. En mode débogage, le compilateur émet des symboles de débogage pour toutes les variables et compile le code tel quel. En mode de libération des optimisations sont inclus:

• variables inutilisées ne sont pas compilées tout
• certaines variables de la boucle sont prises hors de la boucle par le compilateur si elles sont avérées être invariants
Code
• écrit sous La directive #debug n'est pas incluse, etc.

Le reste appartient au JIT.

Edit: Liste complète des optimisations here de courtoisie de Eric Lippert

Answer 2

Je ne peux pas commenter sur les performances, mais le conseil "ne pas déployer le débogage à la production" tient toujours simplement parce que le code de débogage fait généralement pas mal de choses différemment dans les grands produits. D'une part, vous pouvez avoir des commutateurs de débogage actifs et, d'autre part, il y aura probablement des vérifications de sécurité supplémentaires et des sorties de débogage qui n'appartiennent pas au code de production.

Answer 3

Dans msdn ... Site

de presse par rapport à des configurations de débogage

Pendant que vous travaillez toujours sur votre projet , vous construisez généralement votre application en utilisant la configuration de débogage , car cetteLa configurationvous permet d'afficher la valeur des variables et de contrôler l'exécution dans le débogueur. Vous pouvez également créer et tester des versions dans la configuration de la version pour vous assurer que vous n'avez pas introduit de bogues qui se manifestent uniquement sur un type de construction ou sur l'autre. Dans .Programmation NET programmation, ces bogues sont très rares, mais ils peuvent se produire.

Lorsque vous êtes prêt à distribuer votre application à l'utilisateur final, créer une version release , qui sera beaucoup plus petit et auront généralement beaucoup de meilleures performances que la configuration de débogage correspondante. Vous pouvez définir la configuration de génération dans le volet Génération du Concepteur de projets ou dans la barre d'outils Générer. Pour plus d'informations sur , voir Configurations de construction.

Answer 4

De msdn social

Il est pas bien documenté, voici ce que je sais . Le compilateur émet une instance du système System.Diagnostics.DebuggableAttribute. Dans la version de débogage, la propriété IsJitOptimizerEnabled est True, dans la version de la version, elle est False. Vous pouvez voir cet attribut dans l'assemblée manifeste avec ildasm.exe

Le compilateur JIT utilise cet attribut pour désactiver les optimisations qui débogage des difficultés. Les qui déplacent le code comme levage par inversion de boucle. Dans les cas sélectionnés , cela peut faire une grande différence en performance. Pas habituellement cependant.

Le mappage des points d'arrêt à l'exécution adresses est le travail du débogueur. Il utilise le fichier .pdb et l'information générés par le compilateur JIT que fournit l'instruction IL pour coder le mappage d'adresse . Si vous écrivez votre propre débogueur, vous utiliseriez ICorDebugCode :: GetILToNativeMapping().

Le déploiement de débogage sera essentiellement plus lent car les optimisations du compilateur JIT sont désactivées.

Answer 5

Ce que vous lisez est tout à fait valide. La version est généralement plus légère en raison de l'optimisation JIT, sans code de débogage (#IF DEBUG ou [Conditional ("DEBUG")], le chargement des symboles de débogage est minime et l'assemblage est souvent moins important, ce qui réduit le temps de chargement. Les performances différentes sont plus évidentes lors de l'exécution du code dans VS en raison d'un PDB et de symboles plus volumineux qui sont chargés, mais si vous l'exécutez indépendamment, les différences de performance peuvent être moins apparentes. Certains codes optimiseront mieux que d'autres et utilisent les mêmes heuristiques optimisantes que dans les autres langages.

Scott a une bonne explication sur l'optimisation de la méthode en ligne here

Voir this article qui donnent une brève explication pourquoi il est différent dans l'environnement ASP.NET pour le réglage de mise au point et de la libération.

Answer 6

Une chose que vous devriez noter, en ce qui concerne les performances et si le débogueur est attaché ou non, quelque chose qui nous a pris par surprise.

Nous avions un morceau de code, impliquant de nombreuses boucles serrées, qui semblait prendre une éternité à déboguer, mais fonctionnait assez bien tout seul.En d'autres termes, aucun client ou client ne rencontrait de problèmes, mais lorsque nous le déboguâmes, il semblait fonctionner comme de la mélasse.

Le coupable était un Debug.WriteLine dans l'une des boucles serrées, qui crachaient des milliers de messages de journal, laissés par une session de débogage il y a un certain temps. Il semble que lorsque le débogueur est attaché et écoute une telle sortie, il y a un surcoût impliqué qui ralentit le programme. Pour ce code particulier, il était de l'ordre de 0,2-0,3 secondes en exécution seule et de 30 secondes lorsque le débogueur était attaché.

Solution simple cependant, il suffit de supprimer les messages de débogage qui n'étaient plus nécessaires.

Answer 7

Dans une large mesure, cela dépend si votre application est liée au calcul, et ce n'est pas toujours facile à dire, comme dans l'exemple de Lasse. Si j'ai la moindre question sur ce qu'il fait, je l'arrête quelques fois et examine la pile. S'il y a quelque chose de supplémentaire dont je n'ai pas vraiment besoin, ça le voit immédiatement.

Answer 8

Il n'y a aucun article qui "prouve" quelque chose au sujet d'une question de performance. La façon de prouver une affirmation sur l'impact sur les performances d'un changement est de l'essayer dans les deux sens et de le tester dans des conditions réalistes mais contrôlées.

Vous posez une question sur la performance, alors vous vous souciez clairement de la performance. Si vous vous souciez de la performance, alors la bonne chose à faire est de fixer des objectifs de performance et ensuite vous écrire une suite de tests qui suit votre progression par rapport à ces objectifs. Une fois que vous avez une telle suite de tests, vous pouvez facilement l'utiliser pour tester par vous-même la vérité ou la fausseté des déclarations comme "la version de débogage est plus lente".

De plus, vous serez en mesure d'obtenir des résultats significatifs. "Slow" n'a pas de sens car on ne sait pas si c'est une microseconde plus lente ou vingt minutes plus lente. "10% plus lent dans des conditions réalistes" est plus significatif.

Passez le temps que vous auriez passé à rechercher cette question en ligne sur la création d'un appareil répondant à la question. Vous obtiendrez des résultats beaucoup plus précis de cette façon. Tout ce que vous lisez en ligne est juste un devinez sur ce que peut arriver. Raison des faits que vous vous êtes rassemblés, pas des suppositions des autres sur la façon dont votre programme pourrait se comporter.

Answer 9

J'ai récemment rencontré un problème de performance. La liste complète des produits prenait trop de temps, environ 80 secondes. J'ai réglé la DB, amélioré les requêtes et il n'y avait pas de différence. J'ai décidé de créer un TestProject et j'ai découvert que le même processus était exécuté en 4 secondes. Puis j'ai réalisé que le projet était en mode Debug et que le projet de test était en mode Release. J'ai basculé le projet principal en mode Release et la liste complète des produits n'a pris que 4 secondes pour afficher tous les résultats. Résumé: Le mode de débogage est beaucoup plus lent que le mode d'exécution car il conserve les informations de débogage. Vous devriez toujours déployer en mode Relase. Vous pouvez toujours avoir des informations de débogage si vous incluez des fichiers .PDB. De cette façon, vous pouvez enregistrer des erreurs avec des numéros de ligne, par exemple.