Discussion :

[romaintaz]

Hello,

Depuis un bout de temps, je préfère écrire ça :

Code :

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

1
2
3
4
5
6
 
String tmp = null;
for (Iterator it = myList.iterator(); it.hasNext(); ) {
  tmp = (String) it.next();
  ...
}

plutôt que ça :

Code :

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

1
2
3
4
5
 
for (Iterator it = myList.iterator(); it.hasNext(); ) {
  String tmp = (String) it.next();
  ...
}

Je me demandais s'il y avait réellement une différence entre les deux? Par exemple est-ce que l'une des solutions est plus rapide qu'une autre (même si je me doute que la différence est infime) ?

Merci d'éclairer ma lanterne...

[KiLVaiDeN]

Salut,

Oui, la première solution est plus rapide. Je ne sais pas trop si les dernières versions de la JVM optimisent ça, mais dans le deuxième cas tu déclares ta variable à chaque passage de boucle; c'est un peu comme si les variables déclarées dans le contenu de ta boucle étaient locale à cette instance du passage dans la boucle, et regénérée à chaque passage, donc allocation/desallocation de mémoire ( enfin sous Java c'est pas exactement ça, mais un peu équivalent ), alors que dans ta première version tu utilises le même emplacement mémoire sans l'allouer et le désallouer à chaque fois.

A+

[romaintaz]

Merci KiLVaiDeN, ça confirme bien mes pensées.

[KiLVaiDeN]

no problem, pour bien comprendre ça, il suffit de bien comprendre la portée des variables et la notion de blocs.

Code :

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

1
2
3
4
5
 
{
int a = 2;
}
System.out.println(a); // ERREUR

Les variables déclarées à l'interieur d'un bloc n'ont une portée que locale à la boucle. D'où le cas du FOR et l'optimisation.

A+

[adiGuba]

Salut,

Oui, la première solution est plus rapide. Je ne sais pas trop si les dernières versions de la JVM optimisent ça, mais dans le deuxième cas tu déclares ta variable à chaque passage de boucle;

Les compilateurs savent très bien optimisé cela, et bien mieux que nous

On en a déjà parlé il y a quelques temps : Question théorique sur le langage

Le bytecode généré dans le second cas est plus petit que le premier

Et en plus dans le second cas tu ne conserve pas une référence inutilement...

a++

[KiLVaiDeN]

En référent à ton post sur l'autre thread ( que je n'avais pas vu ), je copie colle ce que tu dis :

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
public void method1();
  Code:
   0:   aconst_null
   1:   astore_1
   2:   aload_0
   3:   getfield        #2; //Field untest:Z
   6:   ifeq    24
   9:   aload_0
   10:  invokevirtual   #4; //Method fonctionRenvoyantUnObjet:()Ljava/lang/Object;
   13:  astore_1
   14:  getstatic       #5; //Field java/lang/System.out:Ljava/io/PrintStream;
   17:  aload_1
   18:  invokevirtual   #6; //Method java/io/PrintStream.println:(Ljava/lang/Object;)V
   21:  goto    2
   24:  return

public void method2();
  Code:
   0:   aload_0
   1:   getfield        #2; //Field untest:Z
   4:   ifeq    22
   7:   aload_0
   8:   invokevirtual   #4; //Method fonctionRenvoyantUnObjet:()Ljava/lang/Object;
   11:  astore_1
   12:  getstatic       #5; //Field java/lang/System.out:Ljava/io/PrintStream;
   15:  aload_1
   16:  invokevirtual   #6; //Method java/io/PrintStream.println:(Ljava/lang/Object;)V
   19:  goto    0
   22:  return

Ce que j'ai mit en gras donc parrait être du code "en plus", mais qui te dit que ce n'est pas du code en plus, qui permet de mettre en cache l'emplacement mémoire de la variable utilisée ?

Pour enlever tout doute, et avoir une bonne libération de mémoire, je propose ceci, mais c'est tiré par les cheveux :

Code :

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

1
2
3
4
5
6
7
8
9
    public void method3() {
        {  // Scope de l'objet a
			Object a = null;
			while (untest) {
				a = fonctionRenvoyantUnObjet();
				System.out.println(a);
			}
        } // fin du scope de l'objet a
    }