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.

[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++

[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]

Code :

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

for(int i = 0, n = String.length; i < n ; i++) {..}

Dans une boucle il faut éviter de répéter le même code si on peut le faire qu'une seule fois. Mais encore une fois ce n'est pas une question de syntaxe mais d'algo


(quoique la JVM sait très bien optimisé cela)

Code :

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

1
2
3
 
//  ou
for(Iterator it = ..  ;it.hasNext() ; ){..}

C'est à dire ? Par rapport à quoi ???

Code :

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

1
2
3
4
5
 
// avec la gestion mono-méthode pour :
try{
      Une seul ligne, ou au moins une seule méthode
} catch ...

Pourquoi ??? Là je voudrais bien avoir plus d'info ?

l'exécution de ifNested() est ~= deux fois plus longue que withIf()

On en revient au même : un code avec un algo "propre" fonctionne mieux qu'un code illisible qu'on croit avoir "optimisé"...

Un algo propre est facile à optimiser, que ce soit par le compilateur ou par un développeur si le besoin s'en fait sentir.

Un code "illisible" est généralement difficile à optimiser, parfois même pour le compilateur !!!




En règle général tu gagneras bien plus en performance à penser des algos propre plutôt qu'en cherchant à "optimiser" à tout prix la moindre ligne de code...


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+.

[cylere]

Dans une boucle il faut éviter de répéter le même code si on peut le faire qu'une seule fois. Mais encore une fois ce n'est pas une question de syntaxe mais d'algo

Code :

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

for(Iterator it = ..  ;it.hasNext() ; ){..}

C'est à dire ? Par rapport à quoi ???

plus optimisé que

Code :

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

1
2
3
4
 
Iterator it = .. ;
while(it.hasNext(){
..}

car la référence de l'iterator est incluse dans les paramètres de for, pas de référence externe à la boucle (Cf. : Joshua Bloch)

Code :

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

1
2
3
try{
      Une seul ligne, ou au moins une seule méthode
} catch ...

Pourquoi ??? Là je voudrais bien avoir plus d'info ?

Même source, le compilateur ne peut optimiser "l'intérieur" d'un try (il travaille en séquence entre les accolades)


Bien d'accord sur la lisibilité, mais écrire correctement selon l'Effective Java peut demander un apprentissage bénéfique aux débutants.

Il y a aussi l'utilisation des méthodes statiques style Collections ou Pattern et d'autres pièges bien cachés, à y découvrir

P.S. :
@adiGuba, bravo pour la présentation de Java7

[adiGuba]

car la référence de l'iterator est incluse dans les paramètres de for, pas de référence externe à la boucle (Cf. : Joshua Bloch)

Je ne sais pas si cela a un impact sur les performances. Donc je ne pense pas qu'on puisse parler d'optimisation...
Par contre c'est vrai que c'est plus propre car on ne peut pas utiliser l'Iterator après le while().


Mais de toute manière avec le for-each ce problème disparait :

Code :

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

1
2
3
for (Object o : ...) {
 
}

Même source, le compilateur ne peut optimiser "l'intérieur" d'un try (il travaille en séquence entre les accolades)

Quel chapitre ? J'aimerais en savoir plus là dessus parce que cela me semble vraiment très bizarre...




a++

[thelvin]

Oui, j'avais lu Effective Java, et bien que je me rappelle des exemples sur ces constructions, à un moment où il conseille de réduire la visibilité des références et des variables en général, je me souviens pas du tout qu'il ait expliqué les choses de cette manière.

Personnellement, j'aime pas déclarer des for() à rallonge trop durs à lire, et parfois le for-each n'est pas adapté, auquel cas je me rabats sur un while(). Pour éviter que l'itérateur soit encore utilisé ensuite, je ne mets tout simplement rien ensuite. La méthode s'arrête avec le while. Le compilateur JIT fait des prouesses avec l'éclatement en plein de petites méthodes, pas de raison de se priver.

[adiGuba]

Oui, j'avais lu Effective Java, et bien que je me rappelle des exemples sur ces constructions, à un moment où il conseille de réduire la visibilité des références et des variables en général, je me souviens pas du tout qu'il ait expliqué les choses de cette manière.

Je suis tout à fait d'accord sur le fait de réduire la visibilité des références... surtout lorsque on change de scope (static, instance, local).

Par contre au sein d'une même méthode (local donc), c'est un plus car cela évites les erreurs potentielles, mais cela ne doit pas nuire à la lisibilité


a++

[cylere]

Je ne sais pas si cela a un impact sur les performances. Donc je ne pense pas qu'on puisse parler d'optimisation...
Par contre c'est vrai que c'est plus propre car on ne peut pas utiliser l'Iterator après le while().

On gagne sur un multicore : le fait de désolidariser l'appelant de l'appelé , permet d'optimiser le déclenchement du thread de l'appelé.

J'ai pu le vérifier avec les TimeStamp de création : au lieu de s'échelonner régulièrement, après réorganisation, certains étaient très rapprochés d'autres non, et un gain d'environ 2% sur la création d'une base objet (1Go).

Quel chapitre ? J'aimerais en savoir plus là dessus parce que cela me semble vraiment très bizarre...

Comme je l'ai dit, je n'ai plus le bouquin. C'était la traduction de la première version (à moins que ce soit d'une autre source tout aussi fiable [elle oui, je ne parle pas de ma mémoire]), sans compter le finalize() qui apporte d'autres contraintes

Logiquement du fait que tu essais (try) te donne la main sur le déroulement des instructions.

En revanche, il est facile de le tester dans une boucle.

[adiGuba]

On gagne sur un multicore : le fait de désolidariser l'appelant de l'appelé , permet d'optimiser le déclenchement du thread de l'appelé.

Je ne vois pas le rapport avec le multicore dans une boucle while/for qui est forcément mono-thread !?



Et pour le try/catch je ne comprend pas non plus.
Perso je pense que de vouloir limiter les try/catch à une seule instruction risque surtout de produire un code imbitable voir même erroné !!!


a++

[thelvin]

J'ai pu le vérifier avec les TimeStamp de création : au lieu de s'échelonner régulièrement, après réorganisation, certains étaient très rapprochés d'autres non, et un gain d'environ 2% sur la création d'une base objet (1Go).

Ça vient peut-être d'autre chose que ça... La logique du raisonnement ne tient pas la route, en tout cas.
(Après, des fois, tout ne se passe pas forcément de façon logique, certes.)

[cylere]

Je ne vois pas le rapport avec le multicore dans une boucle while/for qui est forcément mono-thread !?

Cela n'a pas d'impact sur la boucle même, mais son exécution peut être préparée en mémoire et lancée en parallèle lorsque la synchronisation le permet, pendant que les autres instructions s'exécutent.

Et pour le try/catch je ne comprend pas non plus.
Perso je pense que de vouloir limiter les try/catch à une seule instruction risque surtout de produire un code imbitable voir même erroné !!!

Code :

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

1
2
3
4
5
6
7
8
Object o;
try {
        o = monInstruction(..);
} catch ..
...
try {
        instructionSuivante(o);
} catch ..

Cherchez l'erreur possible...

Ça vient peut-être d'autre chose que ça... La logique du raisonnement ne tient pas la route, en tout cas.
(Après, des fois, tout ne se passe pas forcément de façon logique, certes.)

L'ennui c'est que je suis foncièrement réfractaire à toute croyance, à tout arrangement avec la conscience, a toute lâcheté avec la logique :
J'ai appliqué Effective Java précepte après précepte (type d'optimisation par type d'optimisation) et que j'ai chronométré/tracé l'apport de chaque changement.

Certains 'gains' semblaient insignifiant (de l'ordre de 0,2%) d'autres fois cela frôlait les 3%.

Dire que mon point de vue ne tient pas la route, c'est un choix (sans arguments), mais remettre en question le benchmark que j'ai fait ....

[adiGuba]

Cela n'a pas d'impact sur la boucle même, mais son exécution peut être préparée en mémoire et lancée en parallèle pendant que les autres instructions s'exécutent.

Ca ca passe par une librairie, pas par un détail syntaxique !!!


La JVM ne va pas exécuter ton code en parallèle si tu utilises un for à la place d'un while !!!

Cherchez l'erreur ...

Ben c'est super crade car on risque de cumuler les exceptions...
Dans ton exemple si une exception survient dans le premier try/catch on va quand même exécuter le second avec o==null ce qui va fatalement engendrer un NullPointerException.

Si tu as 10 instructions dans 10 try/catch tu auras potentiellement 10 exceptions qui seront remontées


Bref c'est illisible et pas pratique à débugger !
Sans compter qu'il n'y a aucune preuve que cela n'ait une quelconque influence sur les performances !

Au contraire même, je doute que l'utilisation d'un try/catch ait un impact sur les performances. Ce n'est pas le try/catch qui est couteux, mais la création des exceptions !





Franchement je ne saurais que de te conseiller d'éviter toutes ces "astuces" franchement suspectes, et de soigner la lisibilité de ton code à la place !

Dire que mon point de vue ne tient pas la route, c'est un choix (sans arguments), mais remettre en question le benchmark que j'ai fait ....

Désolé mais tu n'a aucun arguments non plus ! Si tu as des benchmark postes-les qu'on puisse vérifier tes dires.



a++

[thelvin]

L'ennui c'est que je suis foncièrement réfractaire à toute croyance, à tout arrangement avec la conscience, a toute lâcheté avec la logique :

Moi aussi.

J'ai appliqué Effective Java précepte après précepte (type d'optimisation par type d'optimisation)

Bon, ça suffit maintenant. Ce n'est pas Effective Java. Effective Java enseigne aux développeurs à être efficaces, pas à faire des programmes à grande efficacité d'exécution.
La lisibilité et la fiabilité du programme y passent toujours avant l'optimisation, tou - jours. En fait, le livre ne parle pas du tout d'optimisation. Il explique que le code propre est naturellement optimisé, parce que c'est ce que Java compte trouver, et c'est ce que Java cherche à optimiser automatiquement.

et que j'ai chronométré/tracé l'apport de chaque changement.

Certains 'gains' semblaient insignifiant (de l'ordre de 0,2%) d'autres fois cela frôlait les 3%.

[...], mais remettre en question le benchmark que j'ai fait ....

Je remets pas en question les benchmarks. Bon, ça a été largement prouvé, les benchmarks c'est comme les analogies : ça marche pas. Mais, je remets jamais la réalité en cause. Parfois, les résultats obtenus ne sont pas logiques : on pourrait s'attendre à ce que quelque chose ait produit de meilleurs résultats, ou les mêmes résultats, qu'autre chose, parce que c'est logique. Mais parfois, ce n'est pas ce que montrent les résultats. Même si c'est pas logique.

Je ne remets pas en cause. Mais je ne les ai pas vus. Et, les résultats sont pas logiques. Je ne sais pas ce que tu as mesuré ni comment. Si ça se trouve c'est un autre facteur qui joue. En fait, si, comme tu le dis, tu fais intervenir une BDD, alors c'est une certitude : c'est un autre facteur qui joue.

Dire que mon point de vue ne tient pas la route, c'est un choix (sans arguments)

Pardon ? Mes arguments auraient été les mêmes que ceux d'adiGuba. Je n'ai juste pas jugé utile de répéter.