Discussion :

[cylere]

Y a-t-il une différence d'optimisation pour Java entre ces deux formulations?

J'ai un vague souvenir disant que la première est plus efficace, en terme de nanoseconde(s) pour le processus de compilation,
mais je n'arrive pas à retrouver l'explication.

Y a-t-il un gourou de la JVM à l'écoute?

[wax78]

A mon avis quedalle. Par contre ca evite les erreurs genre :

Code :

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

if (toto = 5)

qui va assigner 5 a toto et pas faire de test réelement mais jsuis pas un gourou

[JoeChip]

Euh, ça sert à quoi de gagner des nanosecondes à la compilation ? En fait, il vaut mieux écrire "if (machin == null )" parce que c'est plus clair.

[cylere]

Euh, ça sert à quoi de gagner des nanosecondes à la compilation ? En fait, il vaut mieux écrire "if (machin == null )" parce que c'est plus clair.

La compilation du bytecode se faisant à la volée, sur un batch de deux heures j'ai gagné vingt minutes en suivant les conseils de Joshua Bloch dans son livre Effective Java. (hélàs j'ai prété le livre, sans retour).
... et j'ai un peu mieux saisi comment fonctionnait la JVM (sans toutefois la connaître vraiment), les mécanismes d'optimisation des objets et la gestion de la mémoire.

Quand à la clarté de lecture, si toute l'application utilise les mêmes optimisations, elle n'est plus un problème.

L'interrogation de départ : est-ce que placer les constantes ou 'static' a gauche du test permet une meilleure optimisation : la mémoire à allouer n'étant plus 'bornée' à droite
... ou encore : toute la mémoire à réserver est organisée en un seul bloc, seuls les références/paramètres vont occuper de nouveaux segments,
Avec de nombreuse boucles itératives cela peut se traduire en nanosecondes, qui deviennent très nombreuses quand le Garbage Collector s'agite.
et à la fin on gagne 1 ou 1,5 %

Peut-être cela est-il fait à la création du bytecode? mais est-ce que if (x > 0) se transforme en if (0 < x)?

[adiGuba]

La compilation du bytecode se faisant à la volée, sur un batch de deux heures j'ai gagné vingt minutes en suivant les conseils de Joshua Bloch dans son livre Effective Java.
... et j'ai un peu mieux saisi comment fonctionnait la JVM (sans toutefois la connaître vraiment), les mécanismes d'optimisation des objets et la gestion de la mémoire.

Sur des "astuces" de syntaxe comme celle là ? Franchement j'en doute et je demande à voir...


Sinon oui la gestion des objets peut grandement améliorer les perfs, mais c'est une question d'algo et non pas de syntaxe !


a++

[hwoarang]

La question est interessante mais, comme les autres, j'ai tendance a privilégier le code lisible que le code optimisé.

La compilation du bytecode se faisant à la volée, sur un batch de deux heures j'ai gagné vingt minutes en suivant les conseils de Joshua Bloch dans son livre Effective Java. (hélàs j'ai prété le livre, sans retour).

J'ai aussi du mal a croire qu'il y a autant de différence sur ce genre d'optimisation. Je pense plutot que certains conseils sont plus importants. Par exemple utiliser Integer i = Integer.valueof(5); plutot que Integer i = new Integer(5);

Peut-être cela est-il fait à la création du bytecode? mais est-ce que if (x > 0) se transforme en if (0 < x)?

Quand on voit la complexité des optimisations que sont capable de faire les compilateurs, si ca apporte vraiment quelque chose, ce serait etonnant que le compilateur ne le fasse pas tout seul, non?
En tout cas, pour te donner une réponse d'une précision rare, j'ai fait le test de compiler les 2 et de decompiler les class obtenues et ca donne la meme chose.

[cylere]

La question est intéressante mais, comme les autres, j'ai tendance a privilégier le code lisible que le code optimisé.

J'ai aussi du mal a croire qu'il y a autant de différence sur ce genre d'optimisation. Je pense plutôt que certains conseils sont plus importants. Par exemple utiliser Integer i = Integer.valueof(5); plutôt que Integer i = new Integer(5);

Bien sûr, c'est surtout avec les

Code :

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

1
2
3
4
5
6
7
8
 
for(int i = 0, n = String.length; i < n ; i++) {..}
//  ou
for(Iterator it = ..  ;it.hasNext() ; ){..}
// avec la gestion mono-méthode pour :
try{
      Une seul ligne, ou au moins une seule méthode
} catch ...

et autre bonnes pratiques que j'ai eu les meilleurs réponses,
mais j'ai été surpris de découvrir que pour

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
 
  static long ifNested() {
        final StringBuilder sb = new StringBuilder();
        final long t = System.nanoTime();
        for (int i = 0; i < nbIter; i++) {
            sb.append(//
            i % 15 == 0 //
                ? "FizzBuzz" //
                : (i % 3 == 0 //
                    ? "Fizz"//
                    : (i % 5 == 0//
                        ? "Buzz" //
                        : i)));// sb.append(sep);
        }
        final long totT = System.nanoTime() - t;
        System.out.format("ifNested\t%20d\n", totT);
        // sb.append("\n"); System.out.println(sb.toString());
        return totT;
    }

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
  static long withIf() {
        final StringBuilder sb = new StringBuilder();
        final long t = System.nanoTime();
        for (int i = 0; i < nbIter; i++) {
            if (i % 3 == 0) {
                sb.append("Fizz");
                if (i % 5 == 0) {
                    sb.append("Buzz");
                }
            } else if (i % 5 == 0) {
                sb.append("Buzz");
            } else {
                sb.append(i);
            }// sb.append(sep);
        }
        final long totT = System.nanoTime() - t;
        System.out.format("withIf\t\t%20d\n", totT);
        // sb.append("\n");System.out.println(sb.toString());
        return totT;
    }

l'exécution de ifNested() est ~= deux fois plus longue que withIf()
Cette dernière est de toute façon la plus rapide (comparé au méthodes utilisant une ArrayList, la récursivité, Map ou String.+=).
code FizzBuzz à disposition.

[adiGuba]

Salut,

J'ai un vague souvenir disant que la première est plus efficace, en terme de nanoseconde(s) pour le processus de compilation,
mais je n'arrive pas à retrouver l'explication.

Non il n'y a aucune différence de performance...


Mais bon franchement vouloir optimiser une comparaison d'identité il faut le vouloir

A mon avis quedalle. Par contre ca evite les erreurs genre :

Code :

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

if (toto = 5)

qui va assigner 5 a toto et pas faire de test réelement mais jsuis pas un gourou

C'est effectivement la seule utilité de cette syntaxe : le compilateur génère une erreur si on utilise par erreur = à la place de ==, au lieu de faire une affectation :

Code :

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

1
2
3
if (variable = true) // aucune erreur, on affecte true à "variable" 
 
if (true = variable) // ERREUR de compilation

Par contre en Java ceci n'est "utile" que pour les types booléens. Le compilateur génèrera une erreur quoi qu'il arrive pour tout les autres types.


Cette syntaxe est surtout utilisé en C/C++ où il n'y a pas de vrai booléen, et où tous les types sont utilisable comme booléen...


a++

[andry.aime]

Par contre en Java ceci n'est "utile" que pour les types booléens. Le compilateur génèrera une erreur quoi qu'il arrive pour tout les autres types.


Cette syntaxe est surtout utilisé en C/C++ où il n'y a pas de vrai booléen, et où tous les types sont utilisable comme booléen...

+1.
Par contre j'ai l'habitude de mettre les constantes à gauche pour faire la comparaison avec la méthode équal pour éviter d'écrire un test avec un null.
Exemple:

Code :

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

1
2
3
4
5
6
7
8
9
String a = unObjet.recupereUnString();
// au lieu de
if(a!=null && a.equals("test")){
 //bla bla bla
}
// j'utilise
if ("test".equals(a)){
 //bla bla bla
}

A+.