Avantages de l'option 'Optimiser le code' dans la construction de Visual Studio
Une grande partie de notre code de version C # est construit avec l'option "Optimiser le code" désactivée. Je pense que cela a pour but de permettre au code construit en mode Release d'être plus facilement débogué.
Étant donné que nous créons un logiciel de bureau assez simple qui se connecte aux services Web d’arrière-plan (c’est-à-dire une application peu gourmande en ressources processeur), qu’en est-il des conséquences sur les performances?
Et une plate-forme particulière est-elle susceptible d'être plus touchée? Par exemple. multi-processeurs/64 bits.
Les détails complets sont disponibles sur http://blogs.msdn.com/jaybaz_ms/archive/2004/06/28/168314.aspx .
En bref...
En code managé, JITter du runtime effectue presque toute l’optimisation. La différence en IL généré par ce drapeau est assez petite.
Vous êtes la seule personne qui peut répondre à la question "Performance hit". Essayez les deux méthodes, mesurez la performance et voyez ce qui se passe. Le succès peut être énorme ou inexistant; personne qui lit ceci ne sait si "énorme" signifie pour vous une microseconde ou vingt minutes.
Si vous êtes intéressé par les optimisations effectuées par le compilateur C # - plutôt que par la gigue - lorsque le commutateur d'optimisation est activé, voir:
http://blogs.msdn.com/ericlippert/archive/2009/06/11/what-does-the-optimize-switch-do.aspx
En fait, il y a une différence, parfois assez importante. Qu'est-ce qui peut vraiment affecter la performance (car c'est quelque chose dont JIT ne s'occupe pas complètement):
- Variables locales inutiles (c'est-à-dire des cadres de pile plus grands pour chaque appel)
- Trop d'instructions conditionnelles génériques, JIT les traduit de manière assez simple.
Branchement inutile (également mal desservi par un JIT - après tout, il n’a pas trop le temps de faire toutes les optimisations intelligentes)
Donc, si vous faites quelque chose de numérique, activez l'optimisation. Sinon, vous ne verrez aucune différence.
Les optimisations effectuées par le compilateur sont plutôt simples et ne devraient pas affecter l'expérience de vos utilisateurs.
Si vous souhaitez quantifier l'optimisation de votre application, il vous suffit de définir un build non optimisé et optimisé et de comparer les résultats.
Je trouve qu'avec un code complexe et gourmand en ressources processeur (le code que j'utilise est une simulation de Monte Carlo qui peut générer suffisamment de threads pour utiliser à 100% un ordinateur. Ceci a été testé dans un environnement à 36 cœurs), les performances peuvent atteindre 4 fois plus haut! Une simulation qui prend 2 heures prendra environ 9 heures sans l'indicateur d'optimisation. (les chemins sont environ 500 000 et pour chaque chemin, il y a 500 étapes pour environ 2000 objets différents avec un calcul très complexe sur chaque objet).