Discussion :

[stujava]

Bonjour,

J'aimerais votre avis : j'ai un code sous les yeux qui fait ceci :

Code :

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

1
2
3
4
5
6
7
8
 
String soapMessage + " " ;
soapMessage += "chaine de caractères";
soapMessage += "chaine de caractères";
soapMessage += "chaine de caractères";
soapMessage += "chaine de caractères";
...
return soapMessage;

Si mes infos sont bonnes, ceci engendre l'instanciation d'un nouveau String en mémoire à chaque ligne ce qui nous fait autant de String que de lignes, voir plus;

j'aimerais remplacer tout cela par :

Code :

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

1
2
3
4
5
6
7
8
9
 
StringBuffer soapMessage = new StringBuffer();
soapMessage.append("chaine de caractères");
soapMessage.append("chaine de caractères");
soapMessage.append("chaine de caractères");
soapMessage.append("chaine de caractères");
....
 
return soapMessage.toString();

Que je pense moins gourmand.

ai-je raison ou tort ?

Merci pour vos commentaires

Stujava

[hwoarang]

Dans un cas aussi simple, le compilateur va probablement optimiser comme s'il n'y avait qu'une string. Mais si tu fais la meme chose dans une boucle, il vaut mieux utiliser un StringBuilder qui evitera de passer par des chaines temporaires inutiles.

[Cafeinoman]

A vérifier, mais il me semble que si le compilo ne peut pas faire une seule string à la compilation, il créer de lui même un StringBuffer (ou un StringBuilder?) Pour gérer la concaténation. Donc c'est pareil, mais le builder est plus pratique selon moi...

[tchize_]

A vérifier, mais il me semble que si le compilo ne peut pas faire une seule string à la compilation, il créer de lui même un StringBuffer (ou un StringBuilder?) Pour gérer la concaténation.

La concaténation se fait d'office au niveau du compilateur par un StringBuilder. Donc dans le pire des cas (pas d'optimisation possible par le compilateur pour une raison ou une autre), tu auras pour chaque ligne une String ET un StringBuilder instanciés
Difficile de prévoir ce que va faire le compilateur. Il est préférable pour une construction de String progressive de passer par un StringBuilder. Note: StringBuilder, pas StringBuffer. Ce dernier étant synchronisé, il est beaucoup plus lent sur les plateformes multicoeur.

[adiGuba]

Salut,


Je confirme : l'utilisation de l'opérateur + (ou +=) sur une String passe par l'utilisation d'un StringBuilder.
Donc ceci :

Code :

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

soapMessage += "chaine de caractères";

est en réalité équivalent à ceci :

Code :

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

soapMessage = new StringBuilder(soapMessage).append("chaine de caractères").toString();

Il y a donc bien 2 nouveaux objets à chaque ligne (un StringBuilder puis un String).



Il est en effet préférable de passer par un StringBuilder (ou StringBuffer) pour faire cela.
Comme le dit tchize_ on préfèrera StringBuilder qui n'est pas synchronisé (même si cela ne doit pas avoir de gros impact coté performance, car je pense que la JVM peut faire sauter la synchronisation puisqu'on utilise une variable locale).



Toutefois il faut nuancer : la JVM arrive à optimiser les concaténation (via l'option OptimizeStringConcat désormais activé par défaut, et connu défavorablement car elle avait entrainé de gros bugs à la sortie de Java 7).
D'autant plus qu'il est ici question de quelques lignes, ce qui ne devrait avoir aucun impact.
On pourrait donc privilégier l'opérateur + plus lisible.

Voir même ceci qui n'utilisera qu'un seul StringBuilder... voir même aucun si on a des constantes comme ici :

Code :

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

1
2
3
4
5
6
String soapMessage = " " 
	+ "chaine de caractères"
	+ "chaine de caractères"
	+ "chaine de caractères"
	+ "chaine de caractères";
return soapMessage;

(le compilateur peut alors concaténer les constantes dès la compilation)




Bref : l'opérateur + n'est généralement pas un problème.

Ce qui peut être problématique c'est l'opérateur += ou équivalent (ex: s = s + "...") si on l'utilise plusieurs fois car cela entraine à chaque fois la création d'un StringBuilder/String.


Dans un code comme ceux là c'est insignifiant, mais dans une boucle cela peut être catastrophique si on a beaucoup d'itérations.
Par exemple ce simple code est un tueur de CPU :

Code :

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

1
2
3
4
		String s = "";
		for (int i=0; i<100_000; i++) {
			s += i;
		}

Sur mon poste il faut plus de 35 secondes pour en arriver à bout, alors que le code équivalent avec un StringBuilder tourne autour des 40ms :

Code :

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

1
2
3
4
5
		StringBuilder sb = new StringBuilder();
		for (int i=0; i<100_000; i++) {
			sb.append(i);
		}
		String s = sb.toString();

Seul problème le StringBuilder rend le code un peu moins lisible.
C'est juste dommage qu'on ne puisse pas utiliser les opérateurs += et + sur un StringBuilder...



a++


PS : à noter qu'avec Java 9 l'opérateur + ne devrait plus être remplacé par un StringBuilder, mais par l'invocation d'une méthode dynamique.
Cela permettra aux JVMs d'optimiser encore plus facilement l'optimisation des concaténations.