Discussion :

[zeyr2mejetrem]

Bonjour à tous,

J'ai une petite question existentielle concernant le refactoring d'une fonction (en général).
Quel est le code le plus optimisé selon vous ?

Voila le premier code

Code :

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

1
2
3
4
5
 
String unStringQuelconque = unObjet.getStringQuelconque();
if( (unStringQuelconque.equals("A")) || (unStringQuelconque.equals("B")) ){
 // Fait quelque chose de super intéressant :-)
}

Voila le deuxième code

Code :

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

1
2
3
4
 
if( (unObjet.getStringQuelconque().equals("A")) || (unObjet.getStringQuelconque().equals("B")) ){
 // Fait toujours quelque chose de super intéressant :-)
}

En gros ma question est l'instanciation d'une variable est elle préférable dans le cadre d'un traitement à la répétition d'un getter ?
Pourriez vous développer votre réponse en envisageant la conso mémoire et la rapidité d'exécution ? Merci d'avance

PS: Je sais bien que le code 2 est moins lisible

[tchize_]

Tout dépend de ce que fait le getter. Si il est basique on peux le répéter. Par contre là, c'est surtout la lisibilité du code qui dois jouer. Donc:

Code :

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

1
2
3
4
String unStringQuelconque = unObjet.getStringQuelconque();
if( (unStringQuelconque.equals("A")) || (unStringQuelconque.equals("B")) ){
 // Fait quelque chose de super intéressant :-)
}

mais

Code :

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

1
2
3
if( (x.getY().equals("A")) || (x.getY().equals("B")) ){
 // Fait toujours quelque chose de super intéressant :-)
}

[zeyr2mejetrem]

Ok. Cependant est on bien d'accord que la consommation mémoire dans le code A et dans le code B sont équivalentes ?

[tchize_]

Ben ca dépend de ce qu'il y a dans le getter.

Code a va nécessiter un peu d'espace de stockage dans la Heap en plus pour la référence (64 bits à priori mais ce n'est pas standardisé la taille d'une référence en java)

[herve91]

Juste pour être plus précis et ne pas introduire d'ambiguïté pour zeyr2mejetrem :

Code a va nécessiter un peu d'espace de stockage dans la Stack

Sinon il est préférable d'écrire :

Code :

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

1
2
3
4
String s= unObjet.getStringQuelconque();
if ("A".equals(s) || "B".equals(s)){
 // Fait quelque chose de super intéressant :-)
}

pour pallier le cas ou s est null.

[tchize_]

Tout à fait herve91, merci de la correction

[wax78]

Tout dépend de ce que fait le getter. Si il est basique on peux le répéter. Par contre là, c'est surtout la lisibilité du code qui dois jouer.

Je viens mettre mon grain de sel. Certe la lisibilité est importante. Mais un call (get) coute du temps.

Donc pourquoi le repeter ?

En effet et tu vas peut etre me contredire mais ce code ultra basique :

package Main;

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
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
public class bench
{
 
	int toto = 16;
 
	/**
         * @param args
         */
	public static void main(String[] args)
	{
		new bench();
 
	}
 
	public bench()
	{
		long start,stop,elapsed;
 
		start=System.currentTimeMillis();
		for (int i = 0; i < 500000; i++)
		{
			fct1();
		}
		stop=System.currentTimeMillis();
		elapsed=stop-start;
		System.err.println("ElapsedFCT1 =="+elapsed);
 
		start=System.currentTimeMillis();
		for (int i = 0; i < 500000; i++)
		{
			fct2();
		}
		stop=System.currentTimeMillis();
		elapsed=stop-start;
		System.err.println("ElapsedFCT2 =="+elapsed);
 
 
		start=System.currentTimeMillis();
		for (int i = 0; i < 500000; i++)
		{
			fct2();
		}
		stop=System.currentTimeMillis();
		elapsed=stop-start;
		System.err.println("ElapsedFCT2 =="+elapsed);
 
		start=System.currentTimeMillis();
		for (int i = 0; i < 500000; i++)
		{
			fct1();
		}
		stop=System.currentTimeMillis();
		elapsed=stop-start;
		System.err.println("ElapsedFCT1 =="+elapsed);
 
 
	}
	private boolean fct1()
	{
		int v = getToto();
		if ((v==15) || (v==17))
		return true;
		return false;
	}
	private boolean fct2()
	{
		if ((getToto()==15) || (getToto()==17))
		return true;
		return false;
	}
 
	public synchronized int getToto()
	{
		return toto;
	}
 
	public synchronized void setToto(int toto)
	{
		this.toto = toto;
	}
 
 
 
}

Qui est a peu pret du meme accabis montre que dans le cas ou l'on doit faire plusieur fois un get (donc un call au lieu d'acceder a la variable directement, ou de la mettre dans une autre variable que l'on rappelera plusieur fois dans le ou les if) il est preferable d'utiliser la FCT1, donc de faire 1 seul get dans une var que l'on compare apres, plutot que 2 fois les get.

Si je regarde le temps ecouler pour FCT1 et FCT2 :

ElapsedFCT1 ==17ms
ElapsedFCT2 ==29ms
ElapsedFCT2 ==29ms
ElapsedFCT1 ==15ms

Alors si j'en crois ce que je constate, un bon gros bloc genre

if (toto.getVariable()==qlqchsoe1) ||(toto.getVariable()==qlqchsoe2) ||(toto.getVariable()==qlqchsoe2) ||(toto.getVariable()==qlqchsoe3))
sera autant plus lent qu'il y'a aura de get (accumulation des temps de call j'imagine).

tandis que :

Object var = toto.getVariable;

if (var==qlqhchose1) || (var==qlqchose2) || (...)

Je me trompe ? (pour avoir dans certains programme (avec de bonne grosses boucles) supprimer des get pour acceder au valeur directement, j'ai vu des petits gains)

[zeyr2mejetrem]

C'était bien mon sentiment premier.

D'un côté on alloue de la mémoire supplémentaire dans la stack et on gagne en vitesse d'exécution.
De l'autre on joue l'économie de mémoire.

Après le tout est de trouver un équillibre.

[wax78]

Personnellement je n'avais même pas "conscience" du fait que ca allait augmenter le stack ^^ mais question rapidité ca oui pour l'avoir déjà essayer

Par contre "pour pallier le cas ou s est null." ca j'aime vraiment bien et je vais tenter de retenir pour eviter les test de null inutile avant mes if

[Rei Ichido]

Juste sur ce dernier point, il vaut mieux que ça pète le plus tôt possible quand un objet est null alors qu'il ne devrait pas l'être ... Maintenant, si c'est normal d'avoir null, alors oui ça économise un test Enfin, pour autant que la méthode equals soit conforme, ie renvoie false quand on lui passe null.