Discussion :

[LeCygne]

Bonjour,

Suite à une étude sur les meilleurs pratiques autour des chaines de caractères, j'en ai conclu que l'opérateur "+" était une très bonne chose. A savoir :

• Les litteraux sont concaténés à la compilation

  Code :

  Sélectionner tout - Visualiser dans une fenêtre à part

  1
  2
  3
  string s1 = "Cette Chaine sera concaténée " +
              "lors de la compilation. L'utilisation " +
              "du \"+\" augmente la lisibilité.";

• Les autres concatenations sont remplacées par un String.Concat qui est très performant. Ce qui signifie que ce code

  Code :

  Sélectionner tout - Visualiser dans une fenêtre à part

  1
  2
  3
  4
  5
  6
  string s1 = "Toutes les ";
  string s2 = "chaines sont ";
  string s3 = "connues avant ";
  string s4 = "l'operation de ";
  string s5 = "concatenation ";
  string s6 = s1 + s2 + s3 + s4 + s5 ;

  génère exactement le même MSIL que le code suivant.

  Code :

  Sélectionner tout - Visualiser dans une fenêtre à part

  1
  2
  3
  4
  5
  6
  string s1 = "Toutes les ";
  string s2 = "chaines sont ";
  string s3 = "connues avant ";
  string s4 = "l'operation de ";
  string s5 = "concatenation ";
  string s6 = String.Concat(s1, s2, s3, s4, s5);

  a savoir, génération d'un tableau de string (car au dela de 4 arguments String.Concat passe par un tableau), puis appel a String.Concat :

  Code :

  Sélectionner tout - Visualiser dans une fenêtre à part

  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
  12
  13
  14
  15
  16
  17
  18
  19
  20
  21
  22
  23
  24
  25
  IL_0187:  ldc.i4.5
  IL_0188:  newarr     [mscorlib]System.String
  IL_018d:  stloc.s    CS$0$0000
  IL_018f:  ldloc.s    CS$0$0000
  IL_0191:  ldc.i4.0
  IL_0192:  ldloc.s    s1
  IL_0194:  stelem.ref
  IL_0195:  ldloc.s    CS$0$0000
  IL_0197:  ldc.i4.1
  IL_0198:  ldloc.s    s2
  IL_019a:  stelem.ref
  IL_019b:  ldloc.s    CS$0$0000
  IL_019d:  ldc.i4.2
  IL_019e:  ldloc.s    s3
  IL_01a0:  stelem.ref
  IL_01a1:  ldloc.s    CS$0$0000
  IL_01a3:  ldc.i4.3
  IL_01a4:  ldloc.s    s4
  IL_01a6:  stelem.ref
  IL_01a7:  ldloc.s    CS$0$0000
  IL_01a9:  ldc.i4.4
  IL_01aa:  ldloc.s    s5
  IL_01ac:  stelem.ref
  IL_01ad:  ldloc.s    CS$0$0000
  IL_01af:  call       string [mscorlib]System.String::Concat(string[])

De plus, String.Concat (donc l'operateur "+" également) s'execute deux fois plus rapidement qu'un String.Format ou qu'un StringBuilder, et utilise également deux fois moins de mémoire que ces deux instructions (PerfView).

En ce qui me concerne l'histoire devrait s'arretter la : l'operateur "+" n'est pas contre-indiqué, voir même mieux que les autres. Mais il parrait que Mr Microsoft déconseille son utilisation, et que Mr Resharper le remplace par String.Format() parce qu'il serait le saint graal de la performance .
Donc si un expert pouvait, soit, confirmer mes observations, soit, expliquer où je me trompe, ce serait super sympa.

[PatteDePoule]

Merci pour l'information! C'est vraiment bon à savoir!

[ericlm128]

J'imagine que l'opérateur + est en fait une conversion implicite retournant un string et qu'il s'agit en effet d'un "string.Concat" dans la fonction.

Il me semble que le stringbuilder est plus performant lors de nombreuses modifications (je sais il est immuable) sur une chaine string (souvent dans une boucle).
Le problème de modifier 1000 fois un string est qu'il va créer 1000 objets en mémoire avec les couts de création et le ramasse miette qui devra les traiter.

[LeCygne]

Merci pour vos réponses.
Effectivement, je n'ai pas voulu assommer tout le monde avec la totalité de l'étude. Mais dès qu'on est dans une boucle de ce genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
// CODE EXEMPLE. PAS FAUX MAIS IL Y A PLUS SIMPLE.
static string ConcatWithStringBuilder(List<String> stringList)
{
    StringBuilder sb = new StringBuilder();
    foreach (string s in stringList)
    {
        sb.Append(s);
    }
    return sb.ToString();
}
CODE EXEMPLE. PAS FAUX MAIS IL Y A PLUS SIMPLE.

il est préférable d'utiliser les StringBuilder.
Il ne faut surtout pas faire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
// NE PAS UTILISER CE CODE !
static string ConcatPerso(List<String> stringList)
{
    string str = string.Empty;
    foreach (string s in stringList)
    {
        str += s;
    }
    return str;
}
// NE PAS UTILISER CE CODE !

Pour être plus précis, ma question serait plutot pourquoi ne pas utiliser l'opérateur "+" (selon Microsoft) et pourquoi préférer la fonction String.Format() (selon Resharper) ?

[jopopmk]

Salut,

dans le cas de la boucle, le StringBuilder est plus performant quelque soit le nombre d'itérations, ou il y a un palier ?

[ericlm128]

Je ne sais pas pourquoi il le faudrait mais je trouve ça bien de se poser la question. Voici quelques autres tests de performances qui vont dans ton sens.

http://www.dotnetperls.com/string-concat
http://jacksondunstan.com/articles/3015
http://weblogs.asp.net/jevgeni/appen...-stringbuilder

Peut être que les méthodes de concaténation on été optimiser lors d'une monté de version du FrameWork ?

String.Format utilise en interne un StringBuilder, la question doit donc être la même :
Quand dois je utiliser "+" (ou concat) et quand dois je utiliser StringBuilder (ou StringFormat).

Pour une opération simple "a" + "b" la concaténation "+" est plus rapide du au cout de création de l'objet StringBuilder. StringFormat est donc déconseillé pour des questions de performances.

[Romka]

Je ne saurais pas dire pourquoi l'un est plus performant que l'autre (d'expérience je sais que la concaténation l'est presque toujours). Par contre, je sais pourquoi dans certaines situations je préfère toujours string.Format.
Honnêtement, dans ma vie professionnelle je n'ai jamais rencontré de cas de figure où il fallait que je concatène des strings plusieurs dizaines de milliers de fois dans une boucle... et, de surcroît, avec le souci de gratter seulement quelques millisecondes. SI c'était le cas je ferais du C++.
Par contre, il m'arrive tous les jours de travailler par exemple avec des IHM multilingues. Un exemple tout bête : l'affichage du nom - prénom d'un utilisateur.
Sur la même appli, en français on veut le prénom puis le nom. En Chinois et en japonais, c'est le contraire.
Avec string.Format mon code ne change pas ; parce que dans mes resx. je vais mettre par ex. une ressource "UserNameFormat" valant "{0} {1}" pour la ressource française, et "{1} {0}" pour la ressource Chinoise. Dans le code qui va l'afficher je vais indifféremment appeler "string.Format(maResource, monPrenom, monNom)".
A mon avis c'est ça le truc : le choix dépend de la finalité, c'est une question d'architecture plus que de performance.

[LeCygne]

Merci pour vos réponses

jopopmk

dans le cas de la boucle, le StringBuilder est plus performant quelque soit le nombre d'itérations, ou il y a un palier ?

Pas de palier. Dès 2 chaines, String.Concat est 2 fois plus rapide que StringBuilder

Nombre	2	3	4	5	6
String.Concat	0,252	0,403	0,544	0,721	0,86
StringBuilder	0,734	0,923	1,289	1,457	1,859
StringFormat	0,733	0,949	1,325	1,509	1,878

Concatenation de 2 à 6 chaines de 4096 caractères générées aléatoirement. Test reproduit 100.000 fois. Resultat en seconde)


ericlm128

Je ne sais pas pourquoi il le faudrait mais je trouve ça bien de se poser la question. Voici quelques autres tests de performances qui vont dans ton sens.

• dotnetperls => http://www.dotnetperls.com/string-concat
  Va dans mon sens. Il parle de String.Join que je vais observer plus en détail avec String.Format (voir le msil)
• jacksondunstan => http://jacksondunstan.com/articles/3015
  Très agréable à lire.
  Va dans mon sens, mais une reponse à la fin donne un cas ou string.format est plus rapide (de peu) dans le cas où il est utilisé pour faire ce qu'il doit faire : Du formatage d'argument. Je vais également ajouter un cas de test qui tendrait à valider cette théorie.
• Jevgeni Borozna's blog => http://weblogs.asp.net/jevgeni/appen...-stringbuilder
  Les exemples pris sont vraiment au désavantage du "+=" et du String.Format(). Deux bons exemples de ce qu'il ne faut pas faire et quand utiliser un StringBuilder

Romka

A mon avis c'est ça le truc : le choix dépend de la finalité, c'est une question d'architecture plus que de performance. .

Merci pour la facon de faire. Moi qui ais toujours évité d'utiliser cette fonction, peut être qu'un jour... . Ici le problème est vraiment la performance. Et surtout la génération minimale de dechet.

[LeCygne]

Après avoir cherché ce que disait Microsoft sur le sujet, je suis tombé sur ces deux articles où ni l'un ni l'autre ne déconseille l'usage du "+", contrairement à ce que j'ai entendu dire (et pu laisser entendre) :
https://msdn.microsoft.com/fr-fr/library/ms228504.aspx
https://msdn.microsoft.com/en-us/library/ff926074.aspx

[Sehnsucht]

Ça n'a jamais été formellement déconseillé (en tout cas pas par des gens qui s'y connaissent un minimum ; c'est plus de l'ordre de la légende urbaine).
Après + ou Format (ou plus globalement Concat vs StringBuilder) ; c'est simple ; ils n'ont pas le même rôle : Format/Builder c'est pour construire/formatter une chaine et +/concat c'est pour concaténer.

Comment ; j'ai juste traduit les noms ? ah oui c'est plutôt bien fichu du coup
Plus sérieusement on se sert d'un Format/Builder lorsqu'il y a transformation ; normalement pour utiliser les données (métier) en représentation textuelle
et tout ce qui est +/concat sert plutôt rassembler des chaines déjà existantes (ou des littéraux)

[ericlm128]

@LeCygne
Dans ta dernière réponse donnée à Romka tu semble lui prouver le contraire de ce qu'il dit ? :

Romka

dans le cas de la boucle, le StringBuilder est plus performant quelque soit le nombre d'itérations, ou il y a un palier ?

LeCygne

Pas de palier. Dès 2 chaines, String.Concat est 2 fois plus rapide que StringBuilder

J'aimerai bien voir ton code de test car StringBuilder peux lui aussi être plus performant, selon l'utilisation.

[jopopmk]

Effectivement, ma question était dans le cadre de la boucle itérative, lorsque StringBuilder est censé être plus performant

Sinon pour la "légende urbaine" de l'opérateur '+' à éviter, ça viendrait pas plutôt du VB.NET où on dit que pour une concat' il faut préférer l'opérateur '&' à l'opérateur '+' ? (j'y connais pas grand chose en VB).

[Romka]

Pour moi il n'y a pas grand intérêt à comparer les perfs de ces différentes méthodes, vu le nombre d'itérations qu'il faut atteindre pour en apprécier la différence.
Encore une fois je pense que chaque méthode a son cas d'utilisation. Le "+" pour les cas simples, dans des contextes monolingues, par souci de lisibilité et de simplicité. Le Format... pour formater, ou dans des applis multilingues. Le StringBuilder pour des opérations plus complexes (je l'ai utilisé massivement il y a peu, pour de la génération de fichiers CSV).
J'ai vu tellement d'exemples en production, où les dev se faisaient débat sur des trucs comme ça en parlant des perfs, et à côté de ça utilisaient mal LinqToSql par ex., et plombaient les perfs sans le savoir, mais pas de quelques "Tick" par opération, plutôt de plusieurs secondes...

[ericlm128]

Après vérification, je pense que 'LeCygne' voulait plutôt répondre à 'jopopmk' que 'Romka'. Ça met un peu la confusion je préfère le notifier

[Sehnsucht]

Effectivement, ma question était dans le cadre de la boucle itérative, lorsque StringBuilder est censé être plus performant

Sinon pour la "légende urbaine" de l'opérateur '+' à éviter, ça viendrait pas plutôt du VB.NET où on dit que pour une concat' il faut préférer l'opérateur '&' à l'opérateur '+' ? (j'y connais pas grand chose en VB).

Là aussi faut faire le distinguo entre ceux qui s'y connaissent (et savent que le seul opérateur de concaténation en VB.Net c'est &) et les autres (notamment ceux qui utilisent le "mode de compatibilité" Option Strict Off [à savoir conversion implicite avec perte d'info ; liaison tardive (late binding) ; et conversion implicite en object (Dim foo ' sans initialisation ; foo sera de type Object)])

Le problème de ce mode (entre autres c'est que str = "" + 42 avec str déclaré comme chaine fonctionne (comprendre compile) du fait de la conversion implicite restrictive autorisée mais ne fait pas forcément ce qu'on pense ; là à l'exécution ça plantera parce que la chaine "" n'est pas convertible en nombre (parce qu'il tente de faire l'addition et de remettre ça sous forme de chaine pour l'assigner à str.
D'un autre côté, toujours dans ce mode str = "1" + 42 ne plantera pas et str aura pour valeur "43" mais on voit tous bien comment ça peut être casse-gueule

Par contre aucun problème à utiliser str = "" & 42 peut importe le mode ; étant donné que ça se résout en un appel à Concat et str = "foo" + "bar" ne pose aucun problème non plus car l'addition de chaines est automatiquement transformée en concaténation (peut-être pour assurer la pérennité du code pré-existant qui ne pose aucun danger) comme on peut le constater ici


Pour résumer ; à partir du moment où on utilise l'opérateur de concaténation (&) les règles sont les mêmes qu'en C# ; avec + c'est au mieux une erreur signalée par le compilo ou au pire la roulette russe selon comment on l'utilise

[LeCygne]

@ericlm128

Dans ta dernière réponse donnée à Romka tu semble lui prouver le contraire de ce qu'il dit ?

Je ne cherche rien à prouver. Je répondais juste à sa question. Mais je me suis trompé, car je ne lui ai pas donné le cas de la boucle.
Je n'ai pas de chiffre pour le cas de la boucle, car il n'y a pas débat sur ce cas. Et pour les petits volumes, on peu négliger.

J'aimerai bien voir ton code de test car StringBuilder peux lui aussi être plus performant, selon l'utilisation.

Voici les methodes qui comparent avec six chaines. J'en appelle d'autres avec 5, 4, 3 ou deux arguments.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
        private string Concat(string string1, string string2, string string3, string string4, string string5, string string6)
        {
            StringBuilder sb = new StringBuilder(string1.Length + string2.Length + string3.Length + string4.Length + string5.Length + string6.Length + 100);
            sb.Append(string1);
            sb.Append(string2);
            sb.Append(string3);
            sb.Append(string4);
            sb.Append(string5);
            sb.Append(string6);
            return sb.ToString();
        }

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
        private string Concat(string string1, string string2, string string3, string string4, string string5, string string6)
        {
            //string result = string.Empty;
            return string.Concat(string1, string2, string3, string4, string5, string6);
        }

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
        private string Concat(string string1, string string2, string string3, string string4, string string5, string string6)
        {
            //string result = string.Empty;
            return string.Format("{0}{1}{2}{3}{4}{5}", string1, string2, string3, string4, string5, string6);
        }

[Romka]

Tes méthodes de test ne sont pas idéales (par ex. dans celle avec le stringbuilder tu effectues des opérations sur la longueur des chaînes, et pas dans les autres).
D'après ce que j'ai compris Stringbuilder devient meilleur dans certains cas, et s'il est bien initialisé :
http://www.dotnetperls.com/stringbuilder-performance

[Sehnsucht]

Je dois être le rabat-joie de service ; mais à quoi ça sert de comparer des perfs sur des choses qui ne servent pas à la même chose ; et qui plus est sur un "non-code" ; un problème de perf ça ne se règle qu'une fois qu'un goulot d'étranglement a été détecté lors d'une mise en pré-prod et que ce goulot a un effet problématique parce qu'une baisse de perf qui ne gêne pas on s'en fiche un peu ; une fois que ça c'est acté on identifie la source du problème et ensuite on le règle.

À ce moment là à la rigueur on peut imaginer basculer d'une solution à base de StringBuilder à une manipulation de chaine à la mano (exemple au pif pour illustrer ; j'ai pas dit qu'on arriverait forcément à faire mieux)

[LeCygne]

Pour moi il n'y a pas grand intérêt à comparer les perfs de ces différentes méthodes, vu le nombre d'itérations qu'il faut atteindre pour en apprécier la différence.
Encore une fois je pense que chaque méthode a son cas d'utilisation. Le "+" pour les cas simples, dans des contextes monolingues, par souci de lisibilité et de simplicité. Le Format... pour formater, ou dans des applis multilingues. Le StringBuilder pour des opérations plus complexes (je l'ai utilisé massivement il y a peu, pour de la génération de fichiers CSV).
J'ai vu tellement d'exemples en production, où les dev se faisaient débat sur des trucs comme ça en parlant des perfs, et à côté de ça utilisaient mal LinqToSql par ex., et plombaient les perfs sans le savoir, mais pas de quelques "Tick" par opération, plutôt de plusieurs secondes...

Effectivement, je n'ai moi même jamais été très regardant sur la performance. En evitant juste de faire n'importe quoi, je n'ai jamais eu de problème. Je me penche actuellement sur le sujet de la performance car je suis dans le cas d'une application avec plusieurs centaines d'utilisateurs connéctés sur des serveurs dont les garbage collector bloquent la machine pendant 30 secondes toutes les 5 mins.
Le code a été écris par des developpeurs qui ne se sont pas forcement soucié de la mémoire. Il va donc falloir que l'on reprenne tout cela. Mon étude sert à savoir dans quelle direction aller.

Je dois être le rabat-joie de service ; mais à quoi ça sert de comparer des perfs sur des choses qui ne servent pas à la même chose ; et qui plus est sur un "non-code" ; un problème de perf ça ne se règle qu'une fois qu'un goulot d'étranglement a été détecté lors d'une mise en pré-prod et que ce goulot a un effet problématique parce qu'une baisse de perf qui ne gêne pas on s'en fiche un peu ; une fois que ça c'est acté on identifie la source du problème et ensuite on le règle.

À ce moment là à la rigueur on peut imaginer basculer d'une solution à base de StringBuilder à une manipulation de chaine à la mano (exemple au pif pour illustrer ; j'ai pas dit qu'on arriverait forcément à faire mieux)

Il n'y a pas de mal. Je comprends qu'une discussion puisse être lassante si on ne sait pas où elle mêne. Je pense que ma réponse à Romka répond également à ton message.

Finalement, après avoir avancer sur le sujet, je me rends compte que je suis aveugle par rapport à la génération de dechet. Meme avec PerMon et PerfView, les resultats sont difficile à interpreter.

[Romka]

Héhé pour troller un peu, gentiment, je citerais mon patron : "Une journée de consultant .NET = 800 € ; une barrette de RAM 8Go = 40 €"