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

Version imprimable

Voir 40 message(s) de cette discussion en une page

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.

Voir 40 message(s) de cette discussion en une page

Fuseau horaire GMT +2. Il est actuellement 16h01.