Est-il un runtime avantage à l'utilisation de const variables locales?

Question

En dehors de faire en sorte qu'ils ne peuvent pas être modifiés (à hauteur d'une erreur du compilateur), le JIT faire tout optimisations pour const habitants?

Par exemple.

public static int Main(string[] args)
{
    const int timesToLoop = 50;

    for (int i=0; i<timesToLoop; i++)
    {
        // ...
    }
}

Answer 1

L'généré IL est différent (à l'aide de mode de lancement):

using constant local                   using normal local
---------------------------------------------------------------------
.entrypoint                            .entrypoint
.maxstack 2                            .maxstack 2
.locals init (                         .locals init (
    [0] int32 i)                           [0] int32 timesToLoop,
L_0000: ldc.i4.0                           [1] int32 i)
L_0001: stloc.0                        L_0000: ldc.i4.s 50 
L_0002: br.s L_0008                    L_0002: stloc.0 
L_0004: ldloc.0                        L_0003: ldc.i4.0  
L_0005: ldc.i4.1                       L_0004: stloc.1 
L_0006: add                            L_0005: br.s L_000b 
L_0007: stloc.0                        L_0007: ldloc.1 
L_0008: ldloc.0                        L_0008: ldc.i4.1 
L_0009: ldc.i4.s 50                    L_0009: add
L_000b: blt.s L_0004                   L_000a: stloc.1 
L_000d: ret                            L_000b: ldloc.1 
                                       L_000c: ldloc.0 
                                       L_000d: blt.s L_0007
                                       L_000f: ret

Comme vous pouvez le voir, le compilateur remplace toutes les variables usages par la valeur de la constante, ce qui entraîne la réduction de la pile.

Answer 2

J'ai donné le code d'un rapide test de performance, à l'aide de l'Extrait de code du Compilateur. Le code que j'ai utilisé est le suivant:

    public static void Main()
    {
        DateTime datStart = DateTime.UtcNow;
        const int timesToLoop = 1000000;

        for (int i=0; i < timesToLoop; i++)
        {
            WL("Line Number " + i.ToString());
        }

        DateTime datEnd = DateTime.UtcNow;
        TimeSpan tsTimeTaken = datEnd - datStart;
        WL("Time Taken: " + tsTimeTaken.TotalSeconds);
        RL();
    }

Remarque, WL et RL sont tout simplement les méthodes d'aide à lire et à écrire dans la console.

Pour tester la non-constant version, j'ai tout simplement supprimé l' const mot-clé. Les résultats sont surprenants:

                        Time Taken (average of 3 runs)

Using const keyword         26.340s
Without const keyword       28.276s

Je suis conscient que c'est très brouillon n'ready test, mais l'utilisation de l' const mot-clé apparaît à compter comme un valide micro-optimisation.

Answer 3

Votre code (à l'aide de const) sera effectivement compilé en tant que:

public static int Main(string[] args){    
    for (int i=0; i < 50; i++)  
    {

    }
}

alors qu'une variable de compilation comme une variable:

public static int Main(string[] args){
    int timesToLoop = 50;    
    for (int i=0; i < timesToLoop; i++)  
    {

    }
}

Answer 4

Ce n'est pas n'importe où près d'une réponse, juste pensé qu'il serait sympa de partager cela, cependant, l'article ne fait pas mention d'exécution des prestations explicitement:
Norme de codage Règle n ° 2: Utilisation de const dans la mesure du Possible

Extrait:
Raisonnement: L'avantage de l'utilisation de const autant que possible par le compilateur, de l'exécution de la protection involontaire écrit à des données qui doit être en lecture seule.

Answer 5

Une différence est que si vous avez eu une assemblée qui fait référence à un const champ dans une autre assemblée et, plus tard, vous modifié cette valeur, le référencement de l'assemblée serait toujours utiliser l'ancienne valeur jusqu'à ce qu'il a été reconstruit.