Performances en mode débogage et en mode version

Question

J'ai rencontré le paragraphe suivant :

" Debug vs Release " dans l'IDE lorsque vous compilez votre code dans Visual Studio ne fait quasiment aucune différence en termes de performances le code généré est quasiment le même. Le compilateur C# ne fait pas vraiment d'optimisation. Le compilateur C# ne fait que cracher de l'IL et au moment de l'exécution, c'est le JITer qui se charge de l'optimisation. Le JITer dispose d'un mode Debug/Release et cela fait une énorme différence au niveau des performances. Mais cela ne dépend pas du fait que vous exécutiez la configuration Debug ou Release de votre projet, cela dépend du fait qu'un débogueur soit attaché."

La source est aquí et le podcast est aquí .

Quelqu'un peut-il me diriger vers un article de Microsoft qui prouve réellement cela ?

Googler " Performances de C# en débogage par rapport à la version finale "renvoie principalement des résultats disant " Debug a beaucoup d'impact sur les performances ", " la version est optimisée ", et " ne pas déployer le débogage en 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 release, certaines optimisations sont incluses :

• les variables inutilisées ne sont pas compilées du tout
• certaines variables de boucle sont retirées de la boucle par le compilateur s'il est prouvé qu'elles sont des invariants
• le code écrit sous la directive #debug n'est pas inclus, etc.

Le reste est du ressort du JIT.

Liste complète des optimisations aquí de la part de Eric Lippert .

Answer 2

Il n'existe aucun article qui "prouve" quoi que ce soit sur une question de performance. La façon de prouver une affirmation sur l'impact d'un changement sur les performances 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 les performances, donc il est clair que vous vous intéressez aux performances. Si vous vous souciez des performances, la bonne chose à faire est de fixer des objectifs de performance et d'é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éracité ou la fausseté d'affirmations telles que "la version de débogage est plus lente".

Et en plus, vous serez en mesure d'obtenir des résultats significatifs. "Plus lent" n'a aucun sens car on ne sait pas s'il s'agit d'une microseconde plus lente ou de vingt minutes plus lentes. "10% plus lent dans des conditions réalistes" est plus significatif.

Consacrez le temps que vous auriez passé à faire des recherches en ligne sur cette question à la construction d'un appareil qui y répond. Vous obtiendrez des résultats bien plus précis de cette façon. Tout ce que vous lisez en ligne n'est qu'une devinez sur ce que pourrait se produire. Raisonnez à partir de faits que vous avez recueillis vous-même, et non à partir de suppositions d'autres personnes sur la façon dont votre programme pourrait se comporter.

Answer 3

Je ne peux pas faire de commentaires sur les performances, mais le conseil "ne déployez pas le code de débogage vers la production" est toujours valable, simplement parce que le code de débogage fait généralement beaucoup de choses différentes dans les grands produits. D'une part, vous pouvez avoir des interrupteurs de débogage actifs et d'autre part, il y aura probablement des contrôles de sanité redondants supplémentaires et des sorties de débogage qui n'ont pas leur place dans le code de production.

Answer 4

De msdn social

Il n'est pas bien documenté, voici ce qu'il en est ce que je sais. Le compilateur émet une instance de la classe System.Diagnostics.DebuggableAttribute. Dans la version debug, l'instance propriété IsJitOptimizerEnabled est True, dans la version release elle est Faux. Vous pouvez voir cet attribut dans le manifeste de l'assemblage avec ildasm.exe

Le compilateur JIT utilise cet attribut pour désactiver les optimisations qui feraient rendraient le débogage difficile. Celles qui qui déplacent le code comme le levage invariant de boucle. Dans certains cas, cela peut faire une grande différence dans les performances. Mais pas en général.

Correspondance entre les points d'arrêt et l'exécution d'exécution est le travail du débogueur. Il utilise le fichier .pdb et les informations générées par le compilateur JIT qui fournit le mappage des adresses des instructions IL d'adresse de code. Si vous écrivez votre propre débogueur, vous utiliseriez ICorDebugCode::GetILToNativeMapping().

En principe, le déploiement du débogage sera plus lent puisque les optimisations du compilateur JIT sont désactivées.

Answer 5

Sur msdn site...

Configurations Release et Debug

Pendant que vous travaillez encore sur votre projet, vous allez généralement construire votre application en utilisant la fonction debug car cette configuration configuration vous permet de visualiser la valeur des variables et de contrôler l'exécution dans le débogueur. Vous pouvez également créer et tester des builds dans la configuration de version pour vous assurer que vous n'avez pas introduit de bogues que qui ne se manifestent que sur un type de build ou l'autre. Dans .NET Framework de tels bogues sont très rares, mais ils peuvent se produire.

Lorsque vous êtes prêt à distribuer votre application aux utilisateurs finaux, créez une release build, qui sera beaucoup plus plus petite et aura généralement une meilleures performances que la configuration de débogage correspondante. Vous pouvez définir la configuration de construction dans le volet Build du Project Designer, ou dans la barre d'outils Build. Pour plus d'informations informations, voir Configurations de construction.