Performance : String vs StringBuilder et accesseur vs accès direct aux champs

Version imprimable

13/03/2013, 15h03
atha2

Performance : String vs StringBuilder et accesseur vs accès direct aux champs

Bonjour,

Je suis actuellement en train de travailler sur un programme qui demande une certaine optimisation : j'ai une fonction qui selon les cas doit concaténer entre 2 et 7 strings (selon les cas), l'usage de StringBuilder est-t-il approprié ? J'ai lu que dans certain cas le compilateur optimise de lui même en insérant un StringBuilder. Quel sont ces cas ?

Doit-on suivre, aujourd'hui, la recommandation de ne pas essayer d’optimiser, de laisser le Javac faire sont boulot et de garder sont code le plus simple possible ?

Autre point sur lequel je me pose des questions : l'accès a un champs via ses accesseurs plutôt que directement a-t-il un coup ? Encore une fois j'ai lu que dans les cas d'accesseur triviaux (ce qui est mon cas pour l'instant), le Javac va inliner les accesseurs. Mais que va-t-il se passer si je veux rendre mon programme multitreadable et donc ajouter synchronized sur certain accesseur ?

Le Javac va-t-il inliner et ajouter un block synchronized(instance) autour de l'accès à la variable ?

Pour information je travail actuellement avec la version 7 de Java mais j'aurai peut-être besoin de passer mon projet en JEE pour ajouter une GUI.

Salut,

Citation:

Envoyé par atha2

Je suis actuellement en train de travailler sur un programme qui demande une certaine optimisation : j'ai une fonction qui selon les cas doit concaténer entre 2 et 7 strings (selon les cas), l'usage de StringBuilder est-t-il approprié ? J'ai lu que dans certain cas le compilateur optimise de lui même en insérant un StringBuilder. Quel sont ces cas ?

Pourquoi une optimisation ? Cette "fonction" te cause des problèmes de performances ???

Sinon dès que tu utilises l'opérateur + entre deux objets, tu utilises implicitement StringBuilder :
Code:

1 2 3 4 5 String s = "Hello " + name; // Est équivalent à String s = new StringBuilder().append("Hello ").append(name).toString();
L'intérêt d'utiliser StringBuilder directement permet d'éviter de multiple création d'objet :
Code:

1 2 3 4 5 6 7 8 9 String s = "Hello " + name; s += ", Hello " + anotherName; s += " and Hello " + yetAnotherName; // Est équivalent à String s = new StringBuilder().append("Hello ").append(name).toString(); s = new StringBuilder().append(s).append(", Hello ").append(anotherName).toString(); s = new StringBuilder().append(s).append(" and Hello ").append(yetAnotherName).toString();
:arrow: 3 créations d'objets StringBuilder qui sont transformé en String à chaque fois...

Là ca va c'est une petite chaine, mais si tu génère une très grosse chaine comme cela, cela peut vite devenir handicapant (en particulier dans une boucle).

Bien sûr ce code peut tenir en une ligne :
Code:

1 2 3 String s = "Hello " + name + ", Hello " + anotherName + " and Hello " + yetAnotherName;
Et là pas besoin de passer par StringBuilder car c'est fait automatiquement...

Citation:

Envoyé par atha2

Doit-on suivre, aujourd'hui, la recommandation de ne pas essayer d’optimiser, de laisser le Javac faire sont boulot et de garder sont code le plus simple possible ?

Oh oui !!!!

De toute manière, et quelque soit le langage, c'est une erreur de chercher à optimiser dans avoir au préalable bien cibler l'origine des mauvaises performances...

Citation:

Envoyé par atha2

Autre point sur lequel je me pose des questions : l'accès a un champs via ses accesseurs plutôt que directement a-t-il un coup ? Encore une fois j'ai lu que dans les cas d'accesseur triviaux (ce qui est mon cas pour l'instant), le Javac va inliner les accesseurs.

Les accesseurs c'est chiant et lourd à écrire (quoi que on peut les générer automatiquement), mais c'est bien pratique lorsqu'on a besoin d'ajouter des contrôles...

Par contre javac n'inline plus rien du tout depuis Java 1.2 !!!
En effet désormais l'inlining est effectué par la JVM à l'exécution, ce qui permet des optimisation bien plus poussé selon le contexte...

Citation:

Envoyé par atha2

Mais que va-t-il se passer si je veux rendre mon programme multitreadable et donc ajouter synchronized sur certain accesseur ?

Le Javac va-t-il inliner et ajouter un block synchronized(instance) autour de l'accès à la variable ?

Je n'en ai concrètement aucune idée...

Mais sinon tu voudrais faire comment : laisser le champs en accès libre et donc potentiellement non-synchronisé !?!?

a++

D'ailleurs javac fait encore mieux si ces Strings sont constantes :

Code:

1
2
3
4
5
6
7
 
public static final String K0 = "AB";
public static final String K = K0 + "CD";
 
public String test(String name) {
  return K + " : " + name;
}

return ... est équivalent à

Code:

1
2
 
return new StringBuilder().append("ABCD : ").append(name).toString();

13/03/2013, 18h51
atha2
Citation:

Envoyé par adiGuba

Salut,
Pourquoi une optimisation ? Cette "fonction" te cause des problèmes de performances ???

Non pas pour l'instant. Je suis encore en phase de développement. Mais je préfère m'informer avant pour éviter de me retrouver à modifier tout mon code.
Citation:
Envoyé par adiGuba

L'intérêt d'utiliser StringBuilder directement permet d'éviter de multiple création d'objet :

Code:

1 2 3 String s = "Hello " + name; s += ", Hello " + anotherName; s += " and Hello " + yetAnotherName;
C'est justement le genre de code que j'utilise (avec des if en plus pour les ligne 2 et 3, je ne pas donc pas tout mettre en une seule instruction. A part si l'utilisation de l’opérateur ternaire permet de tout transformer en un seul StringBuilder ?)

Citation:

Envoyé par adiGuba

Là ca va c'est une petite chaine, mais si tu génère une très grosse chaine comme cela, cela peut vite devenir handicapant (en particulier dans une boucle).

Un ordre de grandeur du nombre de concaténation à partir duquel ça pourrait devenir handicapant ?

Citation:

Envoyé par adiGuba

Les accesseurs c'est chiant et lourd à écrire (quoi que on peut les générer automatiquement), mais c'est bien pratique lorsqu'on a besoin d'ajouter des contrôles...

Ce n'est pas vraiment un problème je ne les écris jamais, je les génère.
<HS>Le seul truc qui me dérange c'est qu'ils pourrissent la visibilité du code au détriment du code vraiment utile. D’ailleurs si quelqu'un connais un plugin Eclipse (voir IntelliJ ou Netbeans) pour les masquer, je suis preneur. Il y a bien les annotations @getter/setter de google mais bon apt augmente le temps de build de façon drastique (en tout cas c'est la cas avec androidannotation)</HS>

Si je pose la question c'est que dans la plupart des exemples de création de DSL avec ANTLR (générateur de compilateur/interpréteur), les champs des classes sont lus/écrits directement. Ces exemples sont pourtant écrits par un Guru du domaine Terence Parr (créateur d'ANTLR) et tirés de son livre... Il doit bien avoir une raison ?

Citation:

Envoyé par adiGuba

Par contre javac n'inline plus rien du tout depuis Java 1.2 !!!
En effet désormais l'inlining est effectué par la JVM à l'exécution, ce qui permet des optimisation bien plus poussé selon le contexte...

Toujours bon à savoir.

Citation:

Envoyé par adiGuba

Mais sinon tu voudrais faire comment : laisser le champs en accès libre et donc potentiellement non-synchronisé !?!?

Non non, je suis pas fou au point d'essayer (et échouer fatalement) de gérer la synchronisation à l'extérieur d'une classe (merci l'encapsulation au passage) : aujourd'hui mon programme est mono-thread.

Je pose la question des performances car je pourrai avoir besoin (aujourd'hui je ne vois pas lequel mais qui sait ?) de rendre mon programme multi-thread auquel cas je serai bien content d'avoir mes accesseurs.
13/03/2013, 19h06
atha2
Citation:
Envoyé par -gma-

D'ailleurs javac fait encore mieux si ces Strings sont constantes :

Code:

1 2 3 4 5 6 7 public static final String K0 = "AB"; public static final String K = K0 + "CD"; public String test(String name) { return K + " : " + name; }

return ... est équivalent à

Code:

1 2 return new StringBuilder().append("ABCD : ").append(name).toString();
C'est d'ailleurs une des principales raisons d'être des constantes (avec le faite quelle soit constante évidement) : remplacer tout ses usages par sa valeur, si sa valeur est connue à la compilation. Mais dans mon cas, un interpréteur, les strings sont récupérés pour la plupart dans le script ; à l'exécution.
13/03/2013, 19h43
adiGuba

Citation:

Envoyé par atha2

C'est justement le genre de code que j'utilise (avec des if en plus pour les ligne 2 et 3, je ne pas donc pas tout mettre en une seule instruction. A part si l'utilisation de l’opérateur ternaire permet de tout transformer en un seul StringBuilder ?)

Dans ce cas oui un StringBuilder serait plus propre...

Citation:

Envoyé par atha2

Un ordre de grandeur du nombre de concaténation à partir duquel ça pourrait devenir handicapant ?

Je ne saurais dire. Ca dépend de la taille de la chaine et du nombre d'opération.

Ce que je sais c'est que dans une boucle cela peut faire très très mal !!!
Mais là on est plus dans une erreur de développement que dans de l'optimisation ;)

Citation:

Envoyé par atha2

Si je pose la question c'est que dans la plupart des exemples de création de DSL avec ANTLR (générateur de compilateur/interpréteur), les champs des classes sont lus/écrits directement. Ces exemples sont pourtant écrits par un Guru du domaine Terence Parr (créateur d'ANTLR) et tirés de son livre... Il doit bien avoir une raison ?

Aucune idée je ne maitrise pas trop le domaine.
Maintenant dans du code généré cela ne me choque pas tant que cela : s'il y a besoin de modifier quoi que ce soit une régénération et hop c'est bon ;)

Citation:

Envoyé par atha2

Je pose la question des performances car je pourrai avoir besoin (aujourd'hui je ne vois pas lequel mais qui sait ?) de rendre mon programme multi-thread auquel cas je serai bien content d'avoir mes accesseurs.

Je n'ai jamais vu de problème de performance lié à l'utilisation de getter/setter...

a++
13/03/2013, 21h45
atha2
Citation:

Envoyé par adiGuba

Maintenant dans du code généré cela ne me choque pas tant que cela : s'il y a besoin de modifier quoi que ce soit une régénération et hop c'est bon ;)

Sauf que dans ce cas là ce sont des classes qui ne sont pas générées, utilisées en complément des classes générées...

Citation:

Envoyé par adiGuba

Je n'ai jamais vu de problème de performance lié à l'utilisation de getter/setter...

Si je résume :
- programme mono-thread : les accesseurs sont inlinés donc pas de problème de performance.
- programme multithread : les accesseurs sont nécessaires.
=> Utilisation des accesseurs dans tous les cas !

Merci pour toutes ces précisions :ccool: