Discussion :

[ando0098]

Bonjour,

J'ai une question concernant les performances liées à la déclaration et l'instanciation des objets.
Je me demande si la déclaration d'un objet à chaque cycle de boucle est une bonne solution ou le contraire.

Code :

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

1
2
3
4
5
 
                String str;
		for (int i = 0; i < 10000000; i++) {
			str = new String("Bonjour");
		}

ou bien

Code :

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

1
2
3
4
 
		for (int i = 0; i < 10000000; i++) {
			 String str = new String("Bonjour");
		}

Merci d'avance.

[thelvin]

Déclarer un objet n'effectue rien du tout. Seule son affectation (str = quelquechose;) fait quelque chose.

Décider où on fait la déclaration est une question de propreté du code, pas de vitesse d'exécution. L'exécution sera la même.

Et donc, pour la propreté du code, les variables doivent être déclarées le plus tard possible.

(Bon, par contre, instancier avec new une nouvelle String de même valeur que les précédentes à chaque boucle, ça c'est très mauvais question performances.)

[ando0098]

concernant l'objet String, c'est juste un exemple. Ce que j'ai voulu savoir, est ce que la déclaration à l'intérieur de la boucle n'a pas d'effet sur la pile.

[thelvin]

Ma foi, je vais vérifier, mais il n'y a pas de raison que ça fasse une différence. Et le boulot du compilateur, c'est de s'en rendre compte et faire au mieux.

[adiGuba]

Salut,

concernant l'objet String, c'est juste un exemple. Ce que j'ai voulu savoir, est ce que la déclaration à l'intérieur de la boucle n'a pas d'effet sur la pile.

Tu peux vérifier cela en décompilant le code avec javap -c : le bytecode généré est identique (ou presque, puisque ne change que les index des variables).


Ce genre de truc c'est de l'optimisation de bout de chandelle...
Déjà avant de chercher à optimiser il faudrait cibler le problème. Sinon ce n'est que pur perte de temps source de problème potentielle à cause d'optimisation bidon !


Comme le dis thelvin le principal reste la lisibilité et la cohérence du code.Donc si la variable n'est utilisé que dans la boucle, autant la déclarée dedans...

A moins bien sûr que ce soit une constante dont la valeur est identique pendant toute la boucle.


a++

[Beginner.]

Bonsoir,

Question de débutant : ce genre de boucle n'alloue-t-il pas 10000000 d'emplacements pour un objet de type String ?

Si oui quel est l'intérêt ? Car en plus je suppose qu'on obtient uniquement une référence pour le dernier emplacement, non ?

[thelvin]

Question de débutant : ce genre de boucle n'alloue-t-il pas 10000000 d'emplacements pour un objet de type String ?

Ça instancie 10000000 objets String, mais vu que la référence vers chacun d'eux est perdue à la fin de la boucle, il devient immédiatement garbage-collectable et il n'est pas nécessaire de les garder tous en même temps.
A priori, donc, on ne peut pas dire que ça "alloue 10000000 emplacements".

Si oui quel est l'intérêt ?

Comme l'a dit ando0098, cet exemple n'a pas d'intérêt. Il veut simplement savoir si, pour l'exécution, il vaut mieux déclarer une variable objet qui sera écrasée à chaque boucle, à l'intérieur ou à l'extérieur de cette boucle.

Et la réponse est que ça n'a pas d'importance pour l'exécution, mais qu'il est plus propre pour le code, de la déclarer à l'intérieur.

Car en plus je suppose qu'on obtient uniquement une référence pour le dernier emplacement, non ?

Je sais pas trop ce que tu veux dire, mais à la fin de la boucle, il ne reste de référence que vers la dernière String créée, oui. Et encore, ça c'est si la String est déclarée à l'extérieur de la boucle. Si elle l'est à l'intérieur, plus aucune de ces String n'est atteignable après la boucle. Elles sont toutes garbage-collectables, même la dernière.

[Beginner.]

Ça instancie 10000000 objets String, mais vu que la référence vers chacun d'eux est perdue à la fin de la boucle, il devient immédiatement garbage-collectable et il n'est pas nécessaire de les garder tous en même temps.
A priori, donc, on ne peut pas dire que ça "alloue 10000000 emplacements"

Eh bien voici ce que j'ai compris : à la rencontre de l'opérateur new Java alloue un emplacement mémoire. Il n'existe pas d'opérateur pour détruire un objet c'est le garbage-collector qui se charge de libérer l'emplacement alloué. Donc on alloue 10000000 d'emplacements que le garbage-collector devra libérer (sauf le dernier pour lequel on a une référence à l'intérieur de la boucle). Je me demande si ce travail effectué par le garbage-collector prend du temps...

J'ai lu que le garbage-collector ne libérait pas forcément la mémoire immédiatement, dans bon nombre de cas il se déclenche quand le besoin de mémoire se fait sentir donc a un moment donné ce genre de boucle consomme de la mémoire (inutilement), non ?

Enfin j'ai peut-être mal compris...

Comme l'a dit ando0098, cet exemple n'a pas d'intérêt. Il veut simplement savoir si, pour l'exécution, il vaut mieux déclarer une variable objet qui sera écrasée à chaque boucle, à l'intérieur ou à l'extérieur de cette boucle.

Et la réponse est que ça n'a pas d'importance pour l'exécution, mais qu'il est plus propre pour le code, de la déclarer à l'intérieur.

Ok et je me dit que dans les cas où on doit utiliser l'opérateur new il y a là une raison supplémentaire de déclarer à l'extérieur mais bon je me base sur ce que j'ai expliqué ci-dessus et j'ai peut-être mal compris.

Je sais pas trop ce que tu veux dire, mais à la fin de la boucle, il ne reste de référence que vers la dernière String créée, oui. Et encore, ça c'est si la String est déclarée à l'extérieur de la boucle. Si elle l'est à l'intérieur, plus aucune de ces String n'est atteignable après la boucle. Elles sont toutes garbage-collectables, même la dernière.

Oui c'est bien ce que j'ai voulu dire, tu m'as bien compris.

Merci et +1.

[+Guilhem]

Eh bien voici ce que j'ai compris : à la rencontre de l'opérateur new Java alloue un emplacement mémoire. Il n'existe pas d'opérateur pour détruire un objet c'est le garbage-collector qui se charge de libérer l'emplacement alloué. Donc on alloue 10000000 d'emplacements que le garbage-collector devra libérer (sauf le dernier pour lequel on a une référence à l'intérieur de la boucle). Je me demande si ce travail effectué par le garbage-collector prend du temps...

Forcément, cela a un coût. Le développeur gagne en facilité (pas besoin de gérer la mémoire manuellement comme en C ou C++) mais perd en performance. C'est souvent l'argument avancé par les critiques qui jugent Java trop lent et lourd. Après, tout dépend des problématiques auxquelles on est confronté, la plupart du temps la lenteur qu'implique le GC n'est pas si handicapante...

J'ai lu que le garbage-collector ne libérait pas forcément la mémoire immédiatement, dans bon nombre de cas il se déclenche quand le besoin de mémoire se fait sentir donc a un moment donné ce genre de boucle consomme de la mémoire (inutilement), non ?

Oui, tout à fait.

[Mens Pervincet]

Eh bien voici ce que j'ai compris : à la rencontre de l'opérateur new Java alloue un emplacement mémoire. Il n'existe pas d'opérateur pour détruire un objet c'est le garbage-collector qui se charge de libérer l'emplacement alloué. Donc on alloue 10000000 d'emplacements que le garbage-collector devra libérer (sauf le dernier pour lequel on a une référence à l'intérieur de la boucle). Je me demande si ce travail effectué par le garbage-collector prend du temps...

Forcément, cela a un coût. Le développeur gagne en facilité (pas besoin de gérer la mémoire manuellement comme en C ou C++) mais perd en performance. C'est souvent l'argument avancé par les critiques qui jugent Java trop lent et lourd. Après, tout dépend des problématiques auxquelles on est confronté, la plupart du temps la lenteur qu'implique le GC n'est pas si handicapante...

J'ai lu que le garbage-collector ne libérait pas forcément la mémoire immédiatement, dans bon nombre de cas il se déclenche quand le besoin de mémoire se fait sentir donc a un moment donné ce genre de boucle consomme de la mémoire (inutilement), non ?

Oui, tout à fait.

Bonjour, juste une précision, depuis java 7 il n'y a pas d'allocation sur le tas pour ce genre de variable locale, comme expliqué dans cet article:
http://blog.developpez.com/adiguba/p...cape-analysis/
Dans le cas précis la variable str serait donc allouée sur la pile, pas de Garbage Collector donc.

[thelvin]

Et avant cela, un garbage-collector intelligent se rendrait compte qu'il peut les garbage-collecter tout de suite, limitant ainsi les contraintes.

[Beginner.]

Salut,

Merci à vous tous (+Guilhem,thelvin et Mens Pervincet).

Bonjour, juste une précision, depuis java 7 il n'y a pas d'allocation sur le tas pour ce genre de variable locale, comme expliqué dans cet article:
http://blog.developpez.com/adiguba/p...cape-analysis/
Dans le cas précis la variable str serait donc allouée sur la pile, pas de Garbage Collector donc.

Merci pour le lien intéressant. Si je comprends bien les allocations (pour les variables locales) se font dans la pile ce qui signifie quand même une consommation inutile de mémoire durant l'exécution de la méthode.

[JoeChip]

pourquoi "inutile" ?

[Mens Pervincet]

Salut,

Merci à vous tous (+Guilhem,thelvin et Mens Pervincet).



Merci pour le lien intéressant. Si je comprends bien les allocations (pour les variables locales) se font dans la pile ce qui signifie quand même une consommation inutile de mémoire durant l'exécution de la méthode.

Comme l'a dit thelvin, les 2 codes sont équivalents. Il s'agit d'une question de lisibilité et de scope d'utilisation de ta variable. La déclaration d'une variable à l'extérieur ou à l'intérieur de la boucle n'a pas d'impact sur les performances.

[Beginner.]

Comme l'a dit thelvin, les 2 codes sont équivalents. Il s'agit d'une question de lisibilité et de scope d'utilisation de ta variable. La déclaration d'une variable à l'extérieur ou à l'intérieur de la boucle n'a pas d'impact sur les performances.

Je pense que ce qu'il voulait dire c'est que ceci :

Code :

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

1
2
3
4
5
 
                String str;
        for (int i = 0; i < 10000000; i++) {
            str = new String("Bonjour");
        }

est équivalent à cela :

Code :

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

1
2
3
4
 
        for (int i = 0; i < 10000000; i++) {
             String str = new String("Bonjour");
        }

Dans les deux cas l'opérateur new est à l'intérieur de la boucle ce qui implique 10000000 d'allocations mémoire dans la pile et c'est justement cela que je soupçonne d'être mauvais car il y a une consommation inutile de mémoire durant l'exécution de la boucle, inutile car l'allocation d'un seul emplacement suffit.

En conclusion j'écrirais plutôt ceci :

Code :

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

1
2
3
4
 
String str = new String("Bonjour");
 
for (int i = 0; i < 10000000; i++) {...}

[thelvin]

Dans les deux cas l'opérateur new est à l'intérieur de la boucle ce qui implique 10000000 d'allocations mémoire dans la pile et c'est justement cela que soupçonne d'être mauvais car il y a une consommation inutile de mémoire durant l'exécution de la boucle, inutile car l'allocation d'un seul emplacement suffit.

En conclusion j'écrirais plutôt ceci :

Code :

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

1
2
3
String str = new String("Bonjour");
 
for (int i = 0; i < 10000000; i++) {...}

Alors oui, mais bon, c'était pas le sujet, puisque cet exemple est absurde.
La boucle ne fait rien d'autre que d'initialiser une String de même valeur encore et encore, donc ce qu'il faut c'est carrément ne pas avoir de boucle.

Ça ne sert à rien de discuter avec des exemples absurdes. À l'origine, la personne a essayé de préciser ce qu'elle voulait dire, alors on a adapté. Mais toi tu ne dois pas le reprendre.

Voyons ce qu'aurait été un bon exemple pour la question :

Quelle est la différence à l'exécution entre :

Code :

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

1
2
3
4
5
6
7
8
9
void maFonction(String base) {
 
  String numerote;
  for(int i = 0; i < 1000000; i++) {
    numerote = base + i;
    faireQuelqueChoseAvec(numerote):
  }
 
}

et

Code :

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

1
2
3
4
5
6
7
8
void maFonction(String base) {
 
  for(int i = 0; i < 1000000; i++) {
    String numerote = base + i;
    faireQuelqueChoseAvec(numerote):
  }
 
}

Réponse : Aucune. Mais la seconde est plus propre, parce qu'elle utilise le scope correct pour la variable numerote.

[+Guilhem]

En conclusion j'écrirais plutôt ceci :

Code :

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

1
2
3
4
 
String str = new String("Bonjour");
 
for (int i = 0; i < 10000000; i++) {...}

Ah mais ce cas précis tout le monde est d'accord sur le fait qu'il faille écrire ça. Le contraire serait une faute (grave) de programmation.
Mais le sujet évoqué au début de ce topic concerne l'optimisation éventuelle quant à la déclaration de la variable dans ou en dehors de la boucle. Et la réponse c'est que ça revient au même.

Après, cela ne veut pas dire qu'il faut à tout prix proscrire le new dans une boucle. Dans bien des cas c'est nécessaire et on ne peut pas faire autrement.

Edit : grillé

[Beginner.]

+1 à tous les deux pour la peine.

Oui je suis d'accord avec vous pour la première question mais en tant que débutant j'ai tilté sur ces parties :

Bonjour,

J'ai une question concernant les performances liées à la déclaration et l'instanciation des objets.

concernant l'objet String, c'est juste un exemple. Ce que j'ai voulu savoir, est ce que la déclaration à l'intérieur de la boucle n'a pas d'effet sur la pile.

J'ai donc appris quelque chose avec cette discussion.

[questionneuse]

J'arrive un peut tard mais ceux que ça intéresse j'ai fais une petite expérience :
J'ai tester sur des boucles de 10 000 000 000 itérations et chronométré
J'ai testé avec des affectations de type primitif ou d'objet au cas ou ça change quelque chose
J'ai choisi les byte car ça prend moins de place, je n'avais pas envie que le garbage collector intervienne
Je n'instancie pas de nouvel objet dans la boucle, je fais juste une affectation car c'est ça qui nous intéresse

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
 
import chronometre.Chrono;
 
public class Boucle {
 
    public static void main(String[] args) {
        Chrono chrono = new Chrono() ;
        int iMax = 3 ;
        long lMax = 10000000000l ;
 
 
        //type primitif
        byte refTP = (byte)0 ;
 
        //affectation interne
        for(int i=0 ; i<iMax ; i++) {
            chrono.start();
            for(long l=0 ; l<lMax ; l++) {
                byte test1 = refTP ;
            }
            chrono.stop();
            System.out.println("affectation interne, type primitif: "+chrono.getMilliSec()) ;
        }
 
        //affectation externe
        byte test2 ;
        for(int i=0 ; i<iMax ; i++) {
            chrono.start();
            for(long l=0 ; l<lMax ; l++) {
                test2 = refTP ;
            }
            chrono.stop();
            System.out.println("affectation externe, type primitif: "+chrono.getMilliSec()) ;
        }
 
 
        //objet
        Byte refO = new Byte((byte)0) ;
 
        //affectation interne
        for(int i=0 ; i<iMax ; i++) {
            chrono.start();
            for(long l=0 ; l<lMax ; l++) {
                Byte test3 = refO ;
            }
            chrono.stop();
            System.out.println("affectation interne, objet: "+chrono.getMilliSec()) ;
        }
 
 
        //affectation externe
        Byte test4 ;
        for(int i=0 ; i<iMax ; i++) {
            chrono.start();
            for(long l=0 ; l<lMax ; l++) {
                test4 = refO ;
            }
            chrono.stop();
            System.out.println("affectation externe, objet: "+chrono.getMilliSec()) ;
        }
    }
}

paur ceux que ça interesse :

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
 
import java.util.Calendar;
import java.util.Date;
import java.util.GregorianCalendar;
 
 
public class Chrono {
    Calendar m_start = new GregorianCalendar();
    Calendar m_stop = new GregorianCalendar();
    public Chrono() {}
 
    public void start() {
        m_start.setTime(new Date());
    }
 
    public void stop() {
        m_stop.setTime(new Date());
    }
 
    public long getMilliSec() {
        return (m_stop.getTimeInMillis() - m_start.getTimeInMillis());
    }
}

et bien le résultat est (en ms):
affectation interne type primitif: 7978
affectation interne type primitif: 8034
affectation interne type primitif: 7740
affectation externe type primitif: 5173
affectation externe type primitif: 5277
affectation externe type primitif: 5303
affectation interne objet: 7729
affectation interne objet: 7749
affectation interne objet: 8085
affectation externe objet: 5225
affectation externe objet: 5143
affectation externe objet: 5202

on peut donc dire que dans ce cas pour 10 000 000 000 itérations :
pour les 2 cas (types primitifs et objets), les affectations interne prennent 8s
pour les 2 cas, les affectations externes prennent 5s (à la louche)
ce qui fait un gain de 3s en faveur des affectations externes
soit un gain de 3ms tous les 10 000 000 itérations

Donc visiblement ce n'est pas la même chose...
enfin il y a peut être des failles dans mon protocol expérimental

[adiGuba]

Salut,


Tu utilises quelle version de Java ?
Quel est la version retourné par "java -version" ?


a++