permet de comparer deux morceaux de code: et Je pensais toujours que ces morceaux de code sont égaux. Mais après avoir construit ce code (mode de sortie avec optimisation vérifiée) et comparé les méthodes IL générées, j'ai remarqué qu'il existe deux autres instructions IL dans le premier échantillon: 1ème code d'échantillon IL: .maxstack 1 2ème code d'échantillon IL: .MaxStack 1 Peut-être que ce code est optimisé par JIT compiller?
Donc, l'initialisation de la variable Bethod locale avec NULL a-t-elle un impact sur la performance (je comprends que c'est une opération très simple, mais tout cas) et nous devrions l'éviter?
Merci à l'avance.
.Locals init ([0] string str)
IL_0000: LDNULL
IL_0001: STLOC.0
IL_0002: LDSTR "test"
IL_0007: STLOC.0
IL_0008: LDLOC.0
IL_0009: Call Void [Mscorlib] System.console :: Writeeline (String)
IL_000E: RET
.Locals init ([0] string str)
IL_0000: LDSTR "test"
IL_0005: STLOC.0
IL_0006: LDLOC.0
IL_0007: Call Void [Mscorlib] System.console :: Writeeline (String)
IL_000C: RET
3 Réponses :
http: // www .CODINGHORROR.COM / Blog / 2005/07 / FOR-BEST-RESUX-DONT-INITIALIZE-variables.html
Pour résumer de l'article, après avoir exécuté divers points de repère, initialiser un objet à une valeur (soit dans le cadre d'une définition, dans le constructeur de la classe, ou dans le cadre d'une méthode d'initialisation) peut être n'importe où d'environ 10-35 % plus lent sur .NET 1.1 et 2.0. Les compilateurs plus récents peuvent optimiser l'initialisation de la définition. L'article se ferme en recommandant d'éviter l'initialisation en règle générale.
Cette réponse peut ne plus être correcte. Voir @ Mise à jour de @ Marcell-Toth: Stackoverflow.com/Questtions/4751535/...
Il est légèrement plus lent, car le lien Jon.stromer.galley est souligné. Mais la différence est incroyablement petite; probablement sur l'ordre des nanosecondes . À ce niveau, les frais généraux d'utiliser une langue de haut niveau comme c # nains toute différence de performance. Si la performance est une grande partie d'un problème, vous pouvez aussi bien coder dans C ou ASM ou quelque chose.
La valeur de l'écriture CLEAR CODE (peu importe ce que cela signifie pour vous) dépassera de loin l'augmentation de la performance de 0,00001MS en termes de coûts et de prestations. C'est pourquoi C # et d'autres langages de haut niveau existent en premier lieu.
Je reçois que cela soit probablement signifié comme une question académique, et je ne néglige pas la valeur de la compréhension des internes du CLR. Mais dans ce cas, il semble juste que la mauvaise chose de se concentrer.
Aujourd'hui (2019) The .NET Framework et les compilateurs Strong> Strong> sont suffisamment intelligents pour optimiser les initialisations inutiles d'absence . (Avec l'inutile Les deux versions compilent comme Voir mon SharpLab expérience comme référence. Mais bien sûr, les implémentations changent, mais la réponse de Justin est intemporelle: j'ai fait cette expérience de curiosité, dans une situation réelle, concentrez-vous sur la clarté et l'expressivité du code et ignorez les micro-optimisations. stloc.0 - ldloc.0 paire.)
Il est généralement considéré comme une mauvaise forme pour initialiser avec une valeur qui ne sera jamais utilisée, simplement parce qu'elle ajoute de la confusion (il y a un «null» étant affecté qui n'a aucun sens à la logique.) Tout coup de performance associé est négligeable; La première raison est une raison beaucoup plus convaincante de l'éviter.
@Dan Bryany: Merci pour le commentaire. Je suis d'accord avec vous que nous ne devons pas utiliser NULL pour l'initialisation, mais certains développeurs préfèrent l'utiliser pour montrer directement l'initialisation. J'ai un tel dans mon équipe :)
Généralement, je préfère ne pas ne pas déclarer la variable jusqu'à ce qu'elle soit initialisée, car cela limite davantage la portée conceptuelle lorsque vous essayez de comprendre le code (c.-à-d. Les locaux sont aussi locaux que possible à l'endroit où ils sont utilisés.) Un effet secondaire de cette approche est Cette méthode augmente, le placement des locaux a tendance à mettre en évidence les zones du code dans lesquelles de nouvelles méthodes peuvent être extraites.
@Dan Bryant: Parfois, ce n'est pas possible (Exemple classique:
Ligne de cordes; tandis que (vrai) {line = flux.readline (); si (ligne == null) {pause;} // etc.} ). Cependant, je suis d'accord avec vous en général.@Jason: Ce n'est pas un très bon exemple - la «ligne» pourrait certainement être scopée à l'intérieur du corps de la boucle.
@Andrew Medico: Vous êtes trop gentil, c'est un exemple terrible et qui était clairement attachée de moi. Voici un meilleur exemple:
Valeur de chaîne; if (! Dictionary.Cardgevalue (clé, valeur de sortie)) {// quelque chose} .