L'initialisation d'une variable locale avec null a-t-elle un impact sur les performances ?

Question

Comparons deux morceaux de code :

String str = null;
//Possibly do something...
str = "Test";
Console.WriteLine(str);

et

String str;
//Possibly do something...
str = "Test";
Console.WriteLine(str);

J'ai toujours pensé que ces morceaux de code sont égaux. Mais après avoir construit ces codes (en mode Release avec optimisation vérifiée) et comparé les méthodes IL générées, j'ai remarqué qu'il y a deux instructions IL de plus dans le premier échantillon :

1er exemple de code IL :

.maxstack 1
.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::WriteLine(string)
IL_000e : ret

2ème exemple de code IL :

.maxstack 1
.locals init ([0] string str)
IL_0000 : ldstr "Test"
IL_0005 : stloc.0
IL_0006 : ldloc.0
IL_0007 : call void [mscorlib]System.Console::WriteLine(string)
IL_000c : ret

Il est possible que ce code soit optimisé par le compilateur JIT ? Est-ce que l'initialisation de la variable locale bethod avec null a un impact sur la performance (je comprends que c'est une opération très simple mais de toute façon) et nous devrions l'éviter ? Merci d'avance.

Answer 1

http://www.codinghorror.com/blog/2005/07/for-best-results-dont-initialize-variables.html

Pour résumer l'article, après avoir effectué divers tests, l'initialisation d'un objet à une valeur (soit dans le cadre d'une définition, soit dans le constructeur de la classe, soit dans le cadre d'une méthode d'initialisation) peut être plus lente de 10 à 35 % environ sur .NET 1.1 et 2.0. Les compilateurs plus récents peuvent optimiser l'initialisation sur la définition. L'article se termine en recommandant d'éviter l'initialisation en règle générale.

Answer 2

Aujourd'hui (2019), le .NET Framework et le .NET Core Les compilateurs sont assez intelligents pour optimiser les initialisations inutiles. . (Avec l'inutile stloc.0 - ldloc.0 paire.)

Les deux versions compilent en tant que

        .maxstack 8

        ldstr "Test"
        call void [System.Console]System.Console::WriteLine(string)
        ret

Voir mon Expérience SharpLab comme référence.

Bien sûr, les mises en œuvre changent, mais la réponse de Justin est intemporelle : J'ai fait cette expérience par curiosité, dans une situation réelle, concentrez-vous sur la clarté et l'expressivité du code, et ignorez les micro-optimisations.