Discussion :

[noOneIsInnocent]

Bonjour

voilà je "connais " le langage Java mais je ne le maitrise pas .et là en l'occurence j'ai une question d'optimisation

un collegue m'a affirmer que le code suivant est plus performant que le second

Code :

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

1
2
3
4
5
6
7
8
 
//
boolean isEffective = false;
isEffective = monBean.getIsEffective();
if (isEffective) {
 
//traitement
}

et voilà le second code auquel j'avais pensé :

Code :

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

1
2
3
4
5
 
 
if(monBean.getIsEffective){
//traitement
}

ce code se trouve dans une methode qui est appelé très frequemment (pour ne pas dire tres tres.....frequemment ..;-) )

merci d'avance pour vos eclaircissements

[herve91]

Je vote pour le second sans aucun doute (mais je crains que le gain ne soit pas perceptible...) !
dans le premier code, tu initialises isEffective à false pour tout de suite après lui affecter le résultat de la méthode getIsEffective()...
De plus, pourquoi passer par une variable intermédiaire, parfaitement inutile ici.

[afrikha]

ben il suffit de compter le nombre d'instructions!!
dans le premier code tu as exactement les mèmes instructions que dans le second plus d'autres instructions, j'en conclue donc que le second est plus rapide (mème si vu le nombre d'instructions la différence doit étre microscopique)

[mehdi82]

je pense que le 2ième code est plus performant car on teste directement sur la valeur( de retour) boolean de la methode getIsEffective() sans passés par une variable ==> stockage de memoire inutile
Enfin je pense



allezzzzz tous ensemble "Eclipse FOR EVER" [/u]

[noOneIsInnocent]

tout d'abord merci d'avoir repondu à ma question
ensuite :
c'est ce que je pensais aussi mais je n'ai pas compris les explications de mon collegue
je lui redemanderais ça mais j'avais un doute
mais je suis toujours preneur d'autre retour

[noOneIsInnocent]

je suis d'accord qu'au niveau de la complexité il suffit de compter le nombre d'instructions pour se rendre compte que la deuxieme methode est plus efficace

en tout cas merci pour vos retours

[alexismp]

Avec un "while" au lieu du "if", le premier est peut-être plus performant.
Cependant, une JVM digne de ce nom fera les optimisations dynamiques pour rendre une performance similaire à l'exécution de ces deux codes.

[Info-Rital]

Je crois qu'il a raison.
Je m'explique : les JVM actuelles (en tout cas la JVM server) sont capables de zapper completement certaine partie de code, dite "dead code".

Ici il s'agit du contenu du if. L'optimisation ne peut etre faite lors de la compilation car il s'agit d'une variable dynamique.
L'optimisation se fait donc au runtime.

J'utilise cette technique d'optimisation pour faire mes debug.
Par contre je crois qu'il doit déclarer la variable isEffective, en "final".

Par contre l'optimisation ne sera pas faite dans le second code.

Ensuite, si la méthode est appelé très frequemment, il a encore plus raison.
La coût de la variable et de l'instruction intermédiaire est réelement négligeable par rapport à l'optimisation.

On peut encore aller plus loin, si on sait d'avance que la valeur de isEffective reste la même à chaque appel de la méthode, on peut effectuer cette partie :

Code :

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

1
2
final boolean isEffective = false;
isEffective = monBean.getIsEffective();

dans une partie du code qui n'est pas appelé plusieurs fois.

[herve91]

Ici il s'agit du contenu du if. L'optimisation ne peut etre faite lors de la compilation car il s'agit d'une variable dynamique.
L'optimisation se fait donc au runtime.

J'utilise cette technique d'optimisation pour faire mes debug.
Par contre je crois qu'il doit déclarer la variable isEffective, en "final".

Je veux bien croire qu'il y ait optimisation dans le cas où la variable est déclarée "final" et de valeur connue à la compilation (false ou true en l'occurrence), mais dans le cas où la valeur est dynamique, le compilateur ne peut pas optimiser.

Pour le cas où la valeur de getIsEffective() reste constante, il est clair qu'il est inutile de la rappeler à chaque fois, mais c'est quand même un cas peu courant en pratique... Par contre, je ne suis pas sûr de la validité de ton code à cause de la modification d'une variable final déjà initialisée. Plutôt qq chose comme ça :

Code :

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

final boolean isEffective = monBean.getIsEffective();

[Info-Rital]

Je veux bien croire qu'il y ait optimisation dans le cas où la variable est déclarée "final" et de valeur connue à la compilation (false ou true en l'occurrence), mais dans le cas où la valeur est dynamique, le compilateur ne peut pas optimiser.

Pour le cas où la valeur de getIsEffective() reste constante, il est clair qu'il est inutile de la rappeler à chaque fois, mais c'est quand même un cas peu courant en pratique... Par contre, je ne suis pas sûr de la validité de ton code à cause de la modification d'une variable final déjà initialisée. Plutôt qq chose comme ça :

Code :

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

final boolean isEffective = monBean.getIsEffective();

Tu m'as mal compris, c'est ce que j'ai dit, le compilateur ne peux faire l'optimisation directement.
Et c'est justement là que j'ai dit que malgré ce qu'on croit, le premier code est effectivement plus rapide, car le compilateur JIT, HotSpot, peut lui faire l'optimisation car il connait la valeur de la variable. Donc si isEffective est false, le code entre le if devient du "code mort" et est optimisé par la JVM.

Sinon oui tu as raison pour mon code, je suis allé trop vite en reprenant le code de départ et en ajoutant justant "final". Il doit effectivement supprimer la premiere ligne, qui d'une part empeche de compiler,et d'autre part est inutile.

[adiGuba]

Salut,

Info-Rital, il faut plutot utiliser le code suivant :

Code :

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

final boolean isEffective = monBean.getIsEffective();

Car sinon cela ne compile pas car une variable final ne peut pas être modifié

Cela permet de dire à la JVM que la valeur ne changera pas et qu'elle peut donc effectuer des optimisations en conséquence... Maintenant je ne sais pas si le gain est important...


Par contre cela ne peut pas marcher sur une boucle while, car si la valeur ne change pas on peut se retrouver dans une boucle infini...

Je veux bien croire qu'il y ait optimisation dans le cas où la variable est déclarée "final" et de valeur connue à la compilation

Il peut y avoir aussi des optimisations par le compilateur JIT à l'exécution...

Mais globalement je ne pense pas que ce soit vraiment une optimisation dans la plupart des cas...

a++

[adiGuba]

Après quelques tests le gain n'est pas énorme...


Sur plus de 2 millions d'itération (Integer.MAX_VALUE) le gain est minime et variable avec la JVM client : sur ma machine je gagne environ 400ms si la valeur est true alors que je perds 200ms si la valeur est false...

Avec la JVM server il n'y a aucune différence entre les deux codes...


Si ca vous intérresse de tester cela sur votre machine :

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
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
public class Main {
 
	boolean value;
 
	public Main(boolean pValue) {
		this.value = pValue;
	}
 
 
	public void emptyMethod() {
		;
	}
 
	/**
         * @return Returns the value.
         */
	public boolean isValue() {
		return this.value;
	}
 
	public static void test (int iteration, boolean value) {
		long start, stop;
 
		Main m = new Main(value);
 
		// ignore le cache des int
		for (int i=0; i<iteration; i++);
 
		System.out.println( iteration + " iterations avec " + value + " :");
 
		start = System.currentTimeMillis();
		for (int i=0; i<iteration; i++) {
			if (m.isValue()) {
				m.emptyMethod();
			}
		}
		stop = System.currentTimeMillis();
		System.out.println("\t Acces direct      : " + (stop-start) );
 
 
		start = System.currentTimeMillis();
		for (int i=0; i<iteration; i++) {
			final boolean finalValue = m.isValue();
			if (finalValue) {
				m.emptyMethod();
			}
		}
		stop = System.currentTimeMillis();
		System.out.println("\t Variable final    : " + (stop-start) );
	}
 
	public static void main(String[] args) throws Exception {
 
		int iteration = Integer.MAX_VALUE;
		if (args.length>0) {
			try {
				iteration = Integer.parseInt(args[0]);
			} catch (Exception e) {
				System.err.println("Bad args : " + e);
			}
		}
 
		test(iteration, true);
		test(iteration, false);
 
	}
}

a++

[Info-Rital]

Oui effectivement, comme je l'ai dis dans mon post précedant, il faut remplacer le code par ça.

Ensuite j'ai dû peut-être mal m'exprimer dans mon premier post , mais j'ai bien dit qu'il dévait déplacer cette instruction uniquement si il ne change pas à chaque itération, si c'est, une valeur qui ne change pas et qui est valable pour tout le programme.

Et encore une fois, je ne parlais pas de compilation avec javac, mais de compilation JIT avec HotSpot .

Sinon, l'optimisation est effectivement là, elle n'a peut-être pas vraiment d'importance dans une application Swing par exemple, mais dans une application 3D en temps réel, j'y fais gaffe Surtout dans la boucle de rendering.

Edit : Pour ton test, dans mon cas, chaque ms gagné est précieux

[adiGuba]

Oui effectivement, comme je l'ai dis dans mon post précedant, il faut remplacer le code par ça.

Oui désolé mon premier post fait un peu doublons avec celui d'herve91 mais les posts se sont croisé...

Ensuite j'ai dû peut-être mal m'exprimer dans mon premier post , mais j'ai bien dit qu'il dévait déplacer cette instruction uniquement si il ne change pas à chaque itération, si c'est, une valeur qui ne change pas et qui est valable pour tout le programme.

Dans ce cas on est d'accord... j'étais plus dans l'utilisation de beans dont les valeurs pouvaient varier...

Et encore une fois, je ne parlais pas de compilation avec javac, mais de compilation JIT avec HotSpot .

On est d'accord, la plupart des optimisations sont réalisé par le compilateur JIT

Sinon, l'optimisation est effectivement là, elle n'a peut-être pas vraiment d'importance dans une application Swing par exemple, mais dans une application 3D en temps réel, j'y fais gaffe Surtout dans la boucle de rendering.

En effet tu viens de signaler le point le plus important : cela dépend de l'application...
Dans la plupart des cas je ne sais pas si cette optimisation serait utile... alors que cela peut être utile pour des appli 3D et/ou temps réelles (mais je n'ai aucune notion là dessus )

a++

[Coulon Arnaud]

Bonjour,

pour choisir entre ton code et celui indiqué par ton collègue, je ne peux te répondre directement, tout dépend du contexte.

Si tu ne fais qu'un seul accès à la méthode getIsEffective pour une valeur donnée de cette attribut, dans ce cas ton code est plus performant car comme déjà dit il n'y a pas de création de variable supplémentaire.

Par contre, si pour une même valeur, tu as besoin de faire n accès à cette attribut (cas d'une boucle), je pencherais plus pour la solution de ton collègue car l'accès aux variables locales est plus rapide que l'accès via ton objet.
La recommandation de ton collègue doit être encore plus frappante si tu imbriques une série de get et que cette série est réutilisé dans une boucle.

Exemple :

Code de ton collègue en cas de boucle :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
boolean isEffective = monBean.getIsEffective(); 
for (int i=0; i<iteration; i++) { 
...
if (isEffective) { 
 
//traitement 
} 
...
}

Ton code en cas de boucle :

Code :

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

1
2
3
4
5
6
7
8
9
 
for (int i=0; i<iteration; i++) { 
...
if (monBean.getIsEffective()) { 
 
//traitement 
} 
...
}

Arnaud