Discussion :

[bulbo]

Pour remettre mon grain de sel .. declarer une variable en dehors ou dans une boucle n'influe pas sur le GC, la variable va dans tout les cas sur la pile et l'objet cree ira dans le tas.

Maintenant j'aimerais un exemple qui me prouve qu'une variable doit etre obligatoirement declaree dans une boucle .. pour moi ca peut toujours etre a l'exterieur ..
Attention j'ai pas dit que c'etait joli a relire, je dis juste que ca peut etre evite.

Bulbo

[adiGuba]

pour moi déclarer des variables dans une boucle est, sauf justifications, définitivement une horreur que le compilateur ne peut pas optimiser.

Pour moi c'est le contraire : cela ne sert à rien de déclarer une variable en dehors d'une boucle si elle ne doit être utilisé que dans la boucle... (sauf si l'objet restera identique pour toute la boucle, dans ce cas cela évite de le réallouer à chaque fois).

Je ne vois pas comment le compilateur pourrait savoir quand déporter et quand ne pas le faire.

Il me semble que le compilateur ne déporte pas la variable, mais conserve sa référence pour l'itération suivante... donc il ne devrait pas y avoir de différence à l'exécution... [en prévisualisant je viens de voir la remarque de bulbo qui me confirme cela]
De plus cela permet au garbage collector de libérer l'objet au plus tot à la fin de la boucle.

Il ne faut pas oublier que souvent gain de mémoire = gain de performance (moins de passage du gc) même avec des serveurs à 1 Go de RAM.

Oui mais que tu fasses :

Code :

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

1
2
3
4
Object o;
for ( ... ) {
	o = new Object();
}

ou

Code :

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

1
2
3
for ( ... ) {
	Object o = new Object();
}

Il y a autant d'objets créés...

Par contre il est inutile d'utiliser des stringBuffer si on a le code suivant

Code :

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

1
2
 
chaine = "debut de la phrase " +"fin de la phrase";

ça le compilateur sait le faire tout seul.

En effet mais personne n'a dit le contraire. La remarque concernait les boucles du style :

Code :

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

1
2
3
4
String s = "";
for (...) {
	s += ...;
}

Maintenant j'aimerais un exemple qui me prouve qu'une variable doit etre obligatoirement declaree dans une boucle .. pour moi ca peut toujours etre a l'exterieur ..

Rien ne t'oblige à la déclarer en dehors de la boucle...

[jowo]

pour moi déclarer des variables dans une boucle est, sauf justifications, définitivement une horreur que le compilateur ne peut pas optimiser.

D'où as-tu lu cette information? As-tu un lien sur ce sujet? Je veux bien te croire mais il me faut des preuves.

Pour moi, déclarer une variable dans une boucle c'est une excellente pratique . Car dans ce cas, le compilateur sait que cette variable sera utilisée que dans ce bloc. À mon avis, il pourrait donc mieux optimiser son utilisation dans la boucle.

Avec ma philosophie, on pourrait aller jusqu'à l'extrême et déclarer des blocs dans les méthodes.

Exemple:

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
public int XXX(int a) {
  int x;
 
 {
    int b;
    int c;
 
    /* traitement de a à l'aide de b e*/
}
 
{
    int d;
    int e;
 
    /* calcul de x en fonction de a à l'aide de d et e*/
}
 
 return x;
}

Je reconnais que dans ce cas le code devient illisible et dans la pratique je ne programme pas de cette manière .

Je ne suis pas un spécialiste et j'attends avec impatience vos réactions.

[Pietra]

Maintenant j'aimerais un exemple qui me prouve qu'une variable doit etre obligatoirement declaree dans une boucle .. pour moi ca peut toujours etre a l'exterieur ..

non, j'ai eu le cas récemment je parcours un gros fichier servant à initialiser des objets (n lignes de propriétés par objet).
avec une déclaration à l'exterieur tous mes objets avaient exactement les mêmes valeurs (celles du dernier objet du fichier).

Si tu declare ta variable en dehors de la boucle alors tu modifie seulement la valeur dans ta boucle. tu garde la même référence pour toutes tes variables.

Si tu la déclare dans la boucle alors c'est comme si tu avait autant de variable que d'itérations.
Conclusion : le nombre d'objet crées est différent

Donc pour moi c'est confirmé par l'expérience :
déclarer des objets dans une boucle alors que cela n'est pas nécessaire est une abbération


NB : la mémoire est libérée lorsque le garbage collector passe et celui ci se déclenche uniquement lorsque la mémoire disponible est insuffisante.
une variable déclarée avec une protée plus faible est simplement éligible plus tôt pour le gc.
Cette optimisation est donc moins visible que d'autres.

[bulbo]

Dans le cas de boucles imbriquees cela change tout:

Code :

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

1
2
3
4
5
6
7
for (int index1 = 0; index1 < 10; index1++)
{
  for (int index2 = 0; index2 < 10; index2++)
  {
    Object obj = ...
  }
}

La on va empiler dix fois la variable obj alors que si elle avait ete declaree a l'exterieure de la boucle on ne l'aurait empilee qu'une fois..
C'est probablement aussi le cas d'index2 d'ailleurs..

Bulbo

[bulbo]

Maintenant j'aimerais un exemple qui me prouve qu'une variable doit etre obligatoirement declaree dans une boucle .. pour moi ca peut toujours etre a l'exterieur ..

non, j'ai eu le cas récemment je parcours un gros fichier servant à initialiser des objets (n lignes de propriétés par objet).
avec une déclaration à l'exterieur tous mes objets avaient exactement les mêmes valeurs (celles du dernier objet du fichier).

Si tu declare ta variable en dehors de la boucle alors tu modifie seulement la valeur dans ta boucle. tu garde la même référence pour toutes tes variables.

Si tu la déclare dans la boucle alors c'est comme si tu avait autant de variable que d'itérations.
Conclusion : le nombre d'objet crées est différent

Donc pour moi c'est confirmé par l'expérience :
déclarer des objets dans une boucle alors que cela n'est pas nécessaire est une abbération


NB : la mémoire est libérée lorsque le garbage collector passe et celui ci se déclenche uniquement lorsque la mémoire disponible est insuffisante.
une variable déclarée avec une protée plus faible est simplement éligible plus tôt pour le gc.
Cette optimisation est donc moins visible que d'autres.

Hum te vexe pas mais c'est du n'importe quoi .. ou du moins c'est ce qu'il me semble .. tu pourrais mettre un bout de code pour illustrer ton propos ?

Genre une boucle qui alloue plus d'objet si la declaration est dans la boucle au lieu d'etre a l'exterieure ..

Bulbo

[herve91]

Dans le cas de boucles imbriquees cela change tout:

Code :

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

1
2
3
4
5
6
7
for (int index1 = 0; index1 < 10; index1++)
{
  for (int index2 = 0; index2 < 10; index2++)
  {
    Object obj = ...
  }
}

La on va empiler dix fois la variable obj alors que si elle avait ete declaree a l'exterieure de la boucle on ne l'aurait empilee qu'une fois..
C'est probablement aussi le cas d'index2 d'ailleurs..

Bulbo

Attention, il ne faut pas confondre imbrication et empilement. La variable "obj", locale à la seconde boucle, a la portée de cette boucle, i.e. elle n'est pas CONNUE (et donc inaccessible) en dehors de celle-ci.
Donc, le compilateur, suffisamment intelligent, sait qu'il peut réutiliser le MEME emplacement mémoire dans la pile pour y stocker la valeur de cette variable. D'ailleurs cet emplacement peut être très bien réutilisée, lorsqu'on sort de la boucle, pour y stocker une autre variable qui serait déclarée à la suite.
En conclusion, une seule et unique zone mémoire est nécessaire dans la pile pour stocker la référence "obj".

[herve91]

Autre point à éclaircir.... Un empilement de données (sous-entendu dans la pile) a lieu uniquement lors de l'appel d'une méthode.... Rien à voir avec l'imbrication de boucles... J'espère que c'est clair

[herve91]

NB : la mémoire est libérée lorsque le garbage collector passe et celui ci se déclenche uniquement lorsque la mémoire disponible est insuffisante.
une variable déclarée avec une protée plus faible est simplement éligible plus tôt pour le gc.
Cette optimisation est donc moins visible que d'autres.

Non, le GC se déclenche quand bon lui semble, et pas uniquement lorsque la mémoire disponible est insuffisante, sinon les performances de l'appli seraient catastrophiques !! Rappelons que le GC est un thread de basse priorité.
L'élection d'une variable par le GC n'a rien à voir avec sa portée. Il faut distinguer les variables de type primitifs, qui elles sont allouées en pile, que le GC ne connaît pas du tout, des objets qui eux sont créés dans le tas et dont la durée de vie n'a rien à voir avec leur portée.

Code :

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

1
2
3
4
Object getObject() {
  Object o = new Object();
  retrun o;
}

La portée de "o" est la méthode getObject(), maintenant quant à sa durée de vie.......