C# optimise-t-il la concaténation des littéraux de chaîne?

Question

Par exemple, le compilateur sait traduire

string s = "test " + "this " + "function"; 

à

string s = "test this function"; 

et ainsi éviter la perte de performance avec la concaténation de chaîne?

Answer 1

Oui. Ceci est garanti par la spécification C#. Il est à la section 7.18 (de la spécification C# 3.0):

Chaque fois qu'une expression satisfait aux exigences énumérées ci-dessus, l'expression est évaluée à compilation. Cela est vrai même si l'expression est une sous-expression d'une expression plus grande qui contient constructions non constantes.

(Les "exigences énumérées ci-dessus" comprennent l'opérateur + appliqué à deux expressions constantes.)

Voir aussi this question.

Answer 2

Je crois que la réponse est oui, mais vous devez regarder ce que le compilateur recrache ... juste compiler et utiliser réflecteur dessus :-)

Answer 3

Oui. C# n'optimise pas seulement la concaténation des littéraux de chaîne, il réduit également les littéraux de chaînes équivalents en constantes et utilise des pointeurs pour référencer toutes les références à la même constante.

Answer 4

de la bouche des chevaux:

concaténation est le processus consistant à ajouter une chaîne à la fin d'une autre chaîne. Lorsque vous concaténez des littéraux de chaîne ou des constantes de chaîne à l'aide de l'opérateur +, le compilateur crée une chaîne unique. Aucune concaténation d'exécution ne se produit. Cependant, les variables de chaîne peuvent être concaténées uniquement au moment de l'exécution. Dans ce cas, vous devez comprendre les implications de performance des différentes approches.

http://msdn.microsoft.com/en-us/library/ms228504.aspx

Answer 5

Juste une remarque sur un sujet connexe - le compilateur C# aussi « optimiser » plusieurs concaténations impliquant des non-littéraux à l'aide de l'opérateur « + » à un seul appel à une surcharge multi-paramètres de la méthode String.Concat().

Alors

string result = x + y + z; 

compile à quelque chose d'équivalent à

string result = String.Concat(x, y, z); 

plutôt que la possibilité plus naïve:

string result = String.Concat(String.Concat(x, y), z); 

Rien de révolutionnaire, mais voulais juste ajouter ce bit à la discussion sur l'optimisation de la concaténation littérale de chaîne. Je ne sais pas si ce comportement est imposé par la norme linguistique ou non.

Answer 6

J'avais une question similaire, mais à propos de VB.NET au lieu de C#. Le moyen le plus simple de vérifier cela était de voir l'assemblage compilé sous Reflector.

La réponse a été que le compilateur C# et le compilateur VB.NET optimisent la concaténation des littéraux de chaîne.

Answer 7

Oui - Vous pouvez le voir explicitement en utilisant ILDASM.

Exemple:

Voici un programme qui ressemble à votre exemple suivi du code de CIL compilé:

Note: J'utilise la fonction String.Concat() juste pour voir comment le compilateur traite les deux méthodes différentes de concaténation.

Programme

class Program 
{ 
    static void Main(string[] args) 
    { 
     string s = "test " + "this " + "function"; 
     string ss = String.Concat("test", "this", "function"); 
    } 
} 

ILDASM

.method private hidebysig static void Main(string[] args) cil managed 
{ 
    .entrypoint 
    // Code size  29 (0x1d) 
    .maxstack 3 
    .locals init (string V_0, 
      string V_1) 
    IL_0000: nop 
    IL_0001: ldstr  "test this function" 
    IL_0006: stloc.0 
    IL_0007: ldstr  "test" 
    IL_000c: ldstr  "this" 
    IL_0011: ldstr  "function" 
    IL_0016: call  string [mscorlib]System.String::Concat(string, 
                   string, 
                   string) 
    IL_001b: stloc.1 
    IL_001c: ret 
} // end of method Program::Main 

Remarquez comment à IL_0001 le compilateur créé la constante "test de cette fonction", par opposition à la façon dont le compilateur traite le String.Concat () function - qui crée une constante pour chacun des paramètres .Concat(), puis appelle la fonction .Concat().