if (null == object) .. ou if (objet == null) ..

Version imprimable

13/03/2012, 11h25
cylere

if (null == object) .. ou if (objet == null) ..

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?
13/03/2012, 11h27
wax78

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

Code:

if (toto = 5)

qui va assigner 5 a toto et pas faire de test réelement mais jsuis pas un gourou :)
13/03/2012, 11h36
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.
13/03/2012, 11h39
adiGuba
Salut,

Citation:

Envoyé par cylere

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 8O

Citation:

Envoyé par wax78

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

Code:

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:

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++
13/03/2012, 15h01
cylere

Citation:

Envoyé par BenWillard

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)?
13/03/2012, 15h11
adiGuba

Citation:

Envoyé par cylere

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++
13/03/2012, 16h23
hwoarang

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

Citation:

Envoyé par cylere

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);

Citation:

Envoyé par cylere

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.

Citation:

Envoyé par hwoarang

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:

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:

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:

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.

13/03/2012, 17h16
adiGuba
Citation:

Envoyé par cylere

Code:

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)
Citation:
Envoyé par cylere

Code:

1 2 3 // ou for(Iterator it = .. ;it.hasNext() ; ){..}
C'est à dire ? Par rapport à quoi ???
Citation:
Envoyé par cylere

Code:

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 ?

Citation:

Envoyé par cylere

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é"...

:arrow: 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++
13/03/2012, 17h36
andry.aime
Citation:

Envoyé par adiGuba

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:

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+.
13/03/2012, 17h39
cylere
Citation:

Envoyé par adiGuba

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:

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

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

plus optimisé que
Code:

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)
Citation:
Envoyé par adiGuba

Code:

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
13/03/2012, 17h56
adiGuba
Citation:

Envoyé par cylere

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:

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

Envoyé par cylere

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++
13/03/2012, 18h30
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.
13/03/2012, 18h59
adiGuba

Citation:

Envoyé par 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.

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++
14/03/2012, 09h36
cylere

Citation:

Envoyé par adiGuba

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

Citation:

Envoyé par adiGuba

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.
14/03/2012, 09h51
adiGuba

Citation:

Envoyé par cylere

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++
14/03/2012, 10h01
thelvin

Citation:

Envoyé par cylere

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.)
14/03/2012, 10h15
cylere
Citation:

Envoyé par adiGuba

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.

Citation:

Envoyé par adiGuba

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:

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

Citation:

Envoyé par thelvin

Ç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 ....
14/03/2012, 10h43
adiGuba

Citation:

Envoyé par cylere

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 !!!

Citation:

Envoyé par cylere

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.

:arrow: 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 !

Citation:

Envoyé par cylere

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++
14/03/2012, 10h57
thelvin

Citation:

Envoyé par cylere

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.

Citation:

Envoyé par cylere

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.

Citation:

Envoyé par cylere

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.

Citation:

Envoyé par cylere

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.
14/03/2012, 11h43
cylere

A tous, merci de vos réponses et du temps passé à les rédiger.

Il y a des interrogations que je ne sais partager qu'en face-à-face (invariant, ici c'est 2 ou +),
... certainement dû à une démarche naturellement intuitive (encadrée par la réduction des incertitudes et par tous les outils utilisés par la logique).

Ce doit être un modèle en voie d'extinction.
14/03/2012, 17h55
hwoarang

Tu peux aussi poster le code des tests dont tu parles. Je suis sur qu'ils interesseraient ceux qui sont intervenus sur ce fil (dont moi) :) En particulier le benchmark sur l'utilisation d'une instruction par bloc try/catch.
Ca permettrait de voir la fiabilité du test ainsi que l'apport par rapport à la lisibilité.

Citation:

Envoyé par hwoarang

Tu peux aussi poster le code des tests dont tu parles. Je suis sur qu'ils interesseraient ceux qui sont intervenus sur ce fil (dont moi) :) En particulier le benchmark sur l'utilisation d'une instruction par bloc try/catch.
Ca permettrait de voir la fiabilité du test ainsi que l'apport par rapport à la lisibilité.

Pour le programme joint, il s'agissait de découvrir quelles étaient les méthodes les plus efficaces parmi toutes celles fournies par les internautes sur le test FizzBuzz.

La certitude des amateurs de beau code (récursivité, code compact [comme le ifNested que je croyais équivalent au if normal car écrit sous une formulation de type C], normalisé, ...]) ne faisaient pas, à mes yeux, du bon code.

En privilégiant le concept théorique/mathématique sur la compréhension intuitive du langage (qui demande des validations), ils s'éloignent de l'esprit Java qui est très pragmatique (ne serait-ce que par rapport à Smalltalk), qui ressemble à un chef d’œuvre de meilleur artisan, et non à une thèse sur les objets.

D'ailleurs, même si Java ne reste pas 1er (derrières les lignes vieilles lunes de Cobol toujours actives) longtemps, la JVM a encore de beaux jours devant elle.
Je comprends parfaitement mon employeur qui confie la gestion de ses quelques milliards d'euros à Java et non à .net, SmallTalk ou autre merveille.

C'est un point de vue d'un ancien admin en production que tout le monde peut/doit contester ... ou améliorer.

Pour les autres améliorations, je les ai faites en optimisant mon application (base neuronale sur db4o) et je n'ai pas envie de tout recommencer, même si je doit avoir encore quelques log sur un disque.

Je viens de m'apercevoir que qu'Effective Java 2008 était maintenant disponible en PDF.
Déjà en relisant les premières ligne je conserve mon point de vue sur ce livre, même s'il est en désaccord avec certains.

Je vais voir ce que je peux faire comme benchmark pour le try.

Code:

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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
package exercices;
 
import java.util.Hashtable;
 
public class FizzBuzz {
    // time for cum with nbIter=30 > 300; 30 ~= 3000
    final static int nbIter = 30;
    final static String sep = "_";
 
    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;
    }
 
    static long stringPlus() {
        final StringBuilder sb = new StringBuilder();
        final long t = System.nanoTime();
        for (int i = 0; i < nbIter; i++) {
            String x = "";
            x += (i % 3 == 0) ? "Fizz" : "";
            x += (i % 5 == 0) ? "Buzz" : "";
            if ("".equals(x)) {
                x += Integer.toString(i);
            }
            sb.append(x);// sb.append(sep);
        }
        final long totT = System.nanoTime() - t;
        System.out.format("stringPlus\t%20d\n", totT);
        // sb.append("\n"); System.out.println(sb.toString());
        return totT;
    }
 
    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;
    }
 
    static long withArray() {
        final String[] lis = {"FizzBuzz", "", "", "Fizz", "", "Buzz", "Fizz",
            "", "", "Fizz", "Buzz", "", "Fizz", "", "",};
        final StringBuilder sb = new StringBuilder();
        final long t = System.nanoTime();
        for (int i = 0; i < nbIter; i++) {
            final String pos = lis[i % 15];
            sb.append(((0 == pos.length()) ? i : pos));// sb.append(sep);
        }
        final long totT = System.nanoTime() - t;
        System.out.format("withArray\t%20d\n", totT);
        // sb.append("\n"); System.out.println(sb.toString());
        return totT;
    }
 
    static long withTable() {
        final Hashtable<Integer, String> ht = new Hashtable<Integer, String>(8);
        ht.put(0, "FizzBuzz");
        ht.put(3, "Fizz");
        ht.put(5, "Buzz");
        ht.put(6, "Fizz");
        ht.put(9, "Fizz");
        ht.put(10, "Buzz");
        ht.put(12, "Buzz");
        final StringBuilder sb = new StringBuilder();
        final long t = System.nanoTime();
        for (int i = 0; i < nbIter; i++) {
            final String s = ht.get(i % 15);
            sb.append((null == s ? i : s));// sb.append(sep);
        }
        final long totT = System.nanoTime() - t;
        System.out.format("withTable\t%20d\n", totT);
        // sb.append("\n"); System.out.println(sb.toString());
        return totT;
 
    }
 
    static String recursive2(final int nbIter1) {
        if (nbIter1 % 3 == 0) {
            String ret = "Fizz";
            if (nbIter1 % 5 == 0) {
                ret += "Buzz";
            }
            return ret;
        } else if (nbIter1 % 5 == 0) { return "Buzz"; }
        return "" + nbIter1;
    }
 
    static long recursive() {
        final StringBuilder sb = new StringBuilder();
        int n = 0;
        final long t = System.nanoTime();
        while (n < nbIter) {
            sb.append(recursive2(n++));
        }
        final long totT = System.nanoTime() - t;
        System.out.format("recursive\t%20d\n", totT);
        // sb.append("\n");System.out.println(sb.toString());
        return totT;
    }
 
    /*** @param args */
    public static void main(final String[] args) {
        long cum = 0L, cum2 = 0L;
        for (int i = 0; i < 5; i++) {
            System.out.println("------ " + i + " -----");
            final long totSb = stringPlus();
            final long totIn = ifNested();
            final long totWi = withIf();
            final long totWa = withArray();
            final long totWt = withTable();
            final long totRe = recursive();
            System.out.format("... stringPlus/withIf :%5d\n", (totSb * 100)
                / totWi);
            System.out.format("...   ifNested/withIf :%5d\n", (totIn * 100)
                / totWi);
            System.out.format("...  withArray/withIf :%5d\n", (totWa * 100)
                / totWi);
            System.out.format("...  withTable/withIf :%5d\n", (totWt * 100)
                / totWi);
            System.out.format("...  recursive/withIf :%5d\n", (totRe * 100)
                / totWi);
            cum += totIn + totSb + totWi + totWa + totWt + totRe;
            System.out.println("CUMUL (SECOND) == " + cum / 100000000 + "."
                + cum % 100000000 + "\t , diff: " + (cum - cum2));
            cum2 = cum;
        }
    }
}

14/03/2012, 19h10
adiGuba

Donc : la méthode avec l’algorithme le plus simple est la plus performante !!!

C'est un peu l'inverse de tout ce que tu avançais non ?

a++
14/03/2012, 20h13
adiGuba
Et perso j'aurait d'autre chose à redire dans ce benchmark.

Déjà la durée d'exécution des tests qui tourne autour de 20000 nanosecondes, soit 0,02 millisecondes. C'est trop peu pour voir une différence notable...
D'ailleurs on ne connait même pas la précision de nanoTime(). Avec de si petites valeurs il y a de forte chance que les résultat soient faussés.

:arrow: Il serait préférable d'augmenter le jeu de données et d'appeler chaque méthode en boucle plusieurs fois pour augmenter le temps d'exécution. (au moins 0.5s pour chaque test).

Avec -verbose:gc on peut alors voir que le GC mouline pas mal. Le problème c'est que cela peut impacter les temps d'exécutions des autres tests. Il serait préférable de les effectuer dans des exécutions séparées ou de forcer plusieurs appels du GC entre chaque tests...

Même chose pour HotSpot qui peut fausser les premiers résultats. Il serait prudent d'utiliser -XX:+PrintCompilation pour ne prendre en compte que les résultats après toutes les compilations...

Ta méthode "recursive" ne l'est pas...

Enfin tes "optimisations" sont à l'origine des mauvaises performances :

Code:

sb.append(((0 == pos.length()) ? i : pos));

Comme i est un int et pos une String, cela génère un appel vers la méthode sb.append(Object) (avec de l'autoboxing pour le type int).

A l'inverse avec un code comme celui-ci :
Code:

1 2 3 4 if (pos.length()==0) sb.append(i); else sb.append(pos);
Tu appelles bien les bonnes méthode append(int) et append(String), et on obtiens alors un temps proche de "withIf"...

Ce qui revient un peu ce qu'on disait : un algo simple est plus facile à optimiser, que ce soit pour le développeur OU pour le compilateur...

a++
14/03/2012, 21h57
thelvin

Citation:

Envoyé par cylere

Je viens de m'apercevoir que qu'Effective Java 2008 était maintenant disponible en PDF.
Déjà en relisant les premières ligne je conserve mon point de vue sur ce livre, même s'il est en désaccord avec certains.

Bah, et qu'est-ce qu'on doit comprendre par là ?
Effective Java est un très bon bouquin, j'ai jamais entendu dire le contraire. J'ai vu de-ci de-là renier certaines recommandations qui y étaient données, mais en général par des gens qui ne comprenaient pas de quoi ils parlaient.
14/03/2012, 22h02
JoeChip

Citation:

cela frôlait les 3%.

C'est pas gras non plus, c'est probablement inférieur à la marge d'erreur de tes mesures, non ?
15/03/2012, 09h09
deathness
Citation:
Envoyé par adiGuba

Enfin tes "optimisations" sont à l'origine des mauvaises performances :

Code:

sb.append(((0 == pos.length()) ? i : pos));

Comme i est un int et pos une String, cela génère un appel vers la méthode sb.append(Object) (avec de l'autoboxing pour le type int).

A l'inverse avec un code comme celui-ci :

Code:

1 2 3 4 if (pos.length()==0) sb.append(i); else sb.append(pos);

Tu appelles bien les bonnes méthode append(int) et append(String), et on obtiens alors un temps proche de "withIf"...

Ce qui revient un peu ce qu'on disait : un algo simple est plus facile à optimiser, que ce soit pour le développeur OU pour le compilateur...
a++
Tiens je m'étais jamais rendu compte de cette subtilité. Tu m'as appris quelque chose :ccool:

J'ai peut être mémorisé le try à la place du finally dont parle Joshua Bloch.
Je n'ai plus le temps de faire des essais pertinents.

Ci-après le FizzBuzz corrigé (enfin, je l'espère), on peut aussi l'essayer en modulant nbIter,
En dehors de l'erreur sur le récursif, je n'avais pas envisagé l'auto-boxing dans ce cas de figure, merci de ces observations.

Ce test est complétement indépendant des améliorations successives/progressives dont j'ai pu parler par ailleurs.

La relecture de cette discussion est très instructive, et je crois qu'elle peut se terminer, je la marque résolue.

Code:

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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
package exercices;
 
import java.util.Hashtable;
 
public class FizzBuzz {
    // time for cum with nbIter=30 > 300; 30 ~= 3000
    static final int nbIter = 30;
    static final String sep = "_";
 
    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;
    }
 
    static long stringPlus() {
        final StringBuilder sb = new StringBuilder();
        final long t = System.nanoTime();
        for (int i = 0; i < nbIter; i++) {
            String x = "";
            x += (i % 3 == 0) ? "Fizz" : "";
            x += (i % 5 == 0) ? "Buzz" : "";
            if (x.isEmpty()) { // MODIF
                x += Integer.toString(i);
            }
            sb.append(x);// sb.append(sep);
        }
        final long totT = System.nanoTime() - t;
        System.out.format("stringPlus\t%20d\n", totT);
        // sb.append("\n"); System.out.println(sb.toString());
        return totT;
    }
 
    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;
    }
 
    static long withArray() {
        final String[] lis = {"FizzBuzz", "", "", "Fizz", "", "Buzz", "Fizz",
            "", "", "Fizz", "Buzz", "", "Fizz", "", "",};
        final StringBuilder sb = new StringBuilder();
        final long t = System.nanoTime();
        for (int i = 0; i < nbIter; i++) {
            final String pos = lis[i % 15];
            sb.append(((0 == pos.length()) ? i : pos));// sb.append(sep);
        }
        final long totT = System.nanoTime() - t;
        System.out.format("withArray\t%20d\n", totT);
        // sb.append("\n"); System.out.println(sb.toString());
        return totT;
    }
 
    static long withTable() {
        final Hashtable<Integer, String> ht = new Hashtable<Integer, String>(8);
        ht.put(0, "FizzBuzz");
        ht.put(3, "Fizz");
        ht.put(5, "Buzz");
        ht.put(6, "Fizz");
        ht.put(9, "Fizz");
        ht.put(10, "Buzz");
        ht.put(12, "Buzz");
        final StringBuilder sb = new StringBuilder();
        final long t = System.nanoTime();
        for (int i = 0; i < nbIter; i++) {
            final String s = ht.get(i % 15);
            // MODIF
            // http://www.developpez.net/forums/d1196563-2/java/general-java/if-null-object-if-objet-null/#post6561766
            // sb.append((null == s ? i : s));// sb.append(sep);
            if (null == s) {
                sb.append(i);
            } else {
                sb.append(s);
            }
        }
        final long totT = System.nanoTime() - t;
        System.out.format("withTable\t%20d\n", totT);
        // sb.append("\n"); System.out.println(sb.toString());
        return totT;
 
    }
 
    static int recursive(final StringBuilder sb, final int n) {
        if (0 == n) {
            return 1;
        }
        if (n % 3 == 0) {
            sb.insert(0, "Fizz");
            if (n % 5 == 0) {
                sb.insert(0, "Buzz");
            }
        } else
            if (n % 5 == 0) {
                sb.insert(0, "Buzz");
            } else {
                sb.insert(0, n);
            }
        return n + recursive(sb, n - 1);
    }
 
    static long recursive() {
        final StringBuilder sb = new StringBuilder("");
        final long t = System.nanoTime();
        recursive(sb, nbIter);
        final long totT = System.nanoTime() - t;
        System.out.format("recursive\t%20d\n", totT);
        sb.append("\n");
        System.out.println(sb.toString());
        return totT;
    }
 
    /*** @param args */
    public static void main(final String[] args) {
        long cum = 0L, cum2 = 0L;
        for (int i = 0; i < 5; i++) {
            System.out.println("------ " + i + " -----");
            final long totSb = stringPlus();
            final long totIn = ifNested();
            final long totWi = withIf();
            final long totWa = withArray();
            final long totWt = withTable();
            final long totRe = recursive();
            System.out.format("... stringPlus/withIf :%5d\n", (totSb * 100)
                / totWi);
            System.out.format("...   ifNested/withIf :%5d\n", (totIn * 100)
                / totWi);
            System.out.format("...  withArray/withIf :%5d\n", (totWa * 100)
                / totWi);
            System.out.format("...  withTable/withIf :%5d\n", (totWt * 100)
                / totWi);
            System.out.format("...  recursive/withIf :%5d\n", (totRe * 100)
                / totWi);
            cum += totIn + totSb + totWi + totWa + totWt + totRe;
            System.out.println("CUMUL (SECOND) == " + cum / 100000000 + "."
                + cum % 100000000 + "\t , diff: " + (cum - cum2));
            cum2 = cum;
        }
    }
}

15/03/2012, 15h49
adiGuba

Citation:

Envoyé par cylere

J'ai peut être mémorisé le try à la place du finally dont parle Joshua Bloch.

Pour le finally la raison n'est pas non plus à chercher du coté de l'optimisation ou des performances...

Le bloc finally est réservé à des opérateurs de "nettoyages". Si tu effectues plusieurs traitement dans un finally tu augmentes le risque d'exception et donc le fait qu'il ne soit pas exécuté totalement...

a++
15/03/2012, 17h31
deathness

Citation:

Envoyé par adiGuba

Pour le finally la raison n'est pas non plus à chercher du coté de l'optimisation ou des performances...

Le bloc finally est réservé à des opérateurs de "nettoyages". Si tu effectues plusieurs traitement dans un finally tu augmentes le risque d'exception et donc le fait qu'il ne soit pas exécuté totalement...

a++

A quand le finally du finally? :aie:
15/03/2012, 17h57
andry.aime

Citation:

Envoyé par deathness

A quand le finally du finally? :aie:

quoi?

:dehors:
21/03/2012, 10h03
adiGuba
Désolé de remonter la discussion, mais il faut dire qu'elle a eu un effet bénéfique me concernant : il m'a poussé à acheter le livre "Effective Java 2nd edition" (chose que je devais faire depuis un bout de temps d'ailleurs).

Je l'ai seulement un peu feuilleté pour le moment, mais comme je le pensais l'idée qu'on y retrouve n'est pas de produire du code "optimisé" mais du "beau code".
Citation:
Envoyé par cylere

plus optimisé que

Code:

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)
:arrow: J'ai lu ce passage, et il ne parle pas d'optimisation mais de propreté du code.

L'intérêt du for permet de limiter la porté de la variable, ce qui évite de l'utiliser par erreur après la boucle...

Et d'ailleurs avec Java 5.0 il conseille bien d'utiliser le for-étendus (à partir du moment où l'ont n'a pas besoin de la méthode remove() de l'Iterator...

:arrow: Bref l'idée principal du bouquin consiste bel et bien à écrire un code propre et lisible, en utilisant les API/Objets les plus adaptés...

a++