Instanciation d'un objet en dehors d'une boucle vs à l'intérieur

Version imprimable

19/10/2011, 12h28
ando0098

Instanciation d'un objet en dehors d'une boucle vs à l'intérieur
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:

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

1 2 3 4 for (int i = 0; i < 10000000; i++) { String str = new String("Bonjour"); }
Merci d'avance.
19/10/2011, 12h36
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.)
19/10/2011, 12h41
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.
19/10/2011, 14h10
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.
19/10/2011, 14h42
adiGuba

Salut,

Citation:

Envoyé par 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.

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++
19/10/2011, 19h23
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 ?
20/10/2011, 01h18
thelvin

Citation:

Envoyé par Beginner.

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".

Citation:

Envoyé par Beginner.

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.

Citation:

Envoyé par Beginner.

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.
20/10/2011, 22h28
Beginner.

Citation:

Envoyé par thelvin

Ç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...

Citation:

Envoyé par thelvin

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.

Citation:

Envoyé par thelvin

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.
21/10/2011, 00h15
+Guilhem

Citation:

Envoyé par Beginner.

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... ;)

Citation:

Envoyé par Beginner.

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.
21/10/2011, 08h35
Mens Pervincet

Citation:

Envoyé par +Guilhem

Citation:

Envoyé par Beginner

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... ;)

Citation:

Envoyé par Beginner

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.
21/10/2011, 10h20
thelvin

Et avant cela, un garbage-collector intelligent se rendrait compte qu'il peut les garbage-collecter tout de suite, limitant ainsi les contraintes.
23/10/2011, 02h46
Beginner.

Salut,

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

Citation:

Envoyé par 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.
23/10/2011, 10h33
JoeChip

pourquoi "inutile" ?
23/10/2011, 17h41
Mens Pervincet

Citation:

Envoyé par Beginner.

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.
23/10/2011, 18h21
Beginner.
Citation:

Envoyé par Mens Pervincet

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:

1 2 3 4 5 String str; for (int i = 0; i < 10000000; i++) { str = new String("Bonjour"); }
est équivalent à cela :
Code:

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:

1 2 3 4 String str = new String("Bonjour"); for (int i = 0; i < 10000000; i++) {...}
23/10/2011, 18h30
thelvin
Citation:
Envoyé par Beginner.

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:

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:

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:

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.
23/10/2011, 18h35
+Guilhem
Citation:
Envoyé par Beginner.

En conclusion j'écrirais plutôt ceci :

Code:

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é :aie:
23/10/2011, 18h56
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 :

Citation:

Envoyé par ando0098

Bonjour,

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

Citation:

Envoyé par 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.

J'ai donc appris quelque chose avec cette discussion.

expérience

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:

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:

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

22/02/2013, 19h19
adiGuba

Salut,

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

a++
22/02/2013, 19h47
kox2ee

Bonjour, c'est intéressant...
on arrête pas le progrès
Il semble que l'allocation sur la pile de java 7 ait quelques effets :

Java 7 :
affectation interne, type primitif: 3445
affectation interne, type primitif: 3424
affectation interne, type primitif: 3415
affectation externe, type primitif: 3418
affectation externe, type primitif: 3499
affectation externe, type primitif: 3410
affectation interne, objet: 3431
affectation interne, objet: 3427
affectation interne, objet: 3428
affectation externe, objet: 3398
affectation externe, objet: 3421
affectation externe, objet: 3420

Ou si tu es déjà en java 7, questionneuse, il te reste à changer de processeur...
22/02/2013, 20h47
adiGuba

Bon je viens de faire quelques essais, et je pense avoir découvert l'origine du problème : questionneuse semble utiliser la JVM "client".

Lorsqu'on parle performance, on utilise généralement la JVM "server" qui active toutes les optimisations possible... et là on n'a pas de différence d'exécution (comme pour kox2ee).

A l'inverse la JVM client a pour objectif de démarrer l'application le plus rapidement possible, et elle n'effectue donc pas toutes les optimisations possibles.

En utilisant la JVM "client" j'obtiens des résultats similaires à ceux de questionneuse... mais cela ne vient pas de la position de la déclaration de la variable !!!

En effet cela semble plutôt venir de la JVM "client" qui n'optimise pas les premières boucles.
En effet si on inverse l'ordre des boucles, on obtient un résultat inverse !!!

a++
25/02/2013, 10h33
questionneuse

Citation:

Envoyé par adiGuba

Salut,

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

java 1.6.0_26

Je parlais de la version complète, par exemple :

Code:

1
2
3
java version "1.7.0_01"
Java(TM) SE Runtime Environment (build 1.7.0_01-b08)
Java HotSpot(TM) 64-Bit Server VM (build 21.1-b02, mixed mode)

a++

25/02/2013, 10h48
questionneuse

Citation:

Envoyé par adiGuba

En effet cela semble plutôt venir de la JVM "client" qui n'optimise pas les premières boucles.
En effet si on inverse l'ordre des boucles, on obtient un résultat inverse !!!

effectivement le fait d'inverser l'ordre des boucles (donc de faire externe-interne-externe-interne au lieu de interne-externe-interne-externe) inverse les résultats c'est vraiment surprenant, j'ai du mal à comprendre...

affectation externe, type primitif: 7891
affectation externe, type primitif: 7930
affectation externe, type primitif: 8292
affectation interne, type primitif: 5457
affectation interne, type primitif: 5454
affectation interne, type primitif: 5475
affectation externe, objet: 7981
affectation externe, objet: 8056
affectation externe, objet: 7896
affectation interne, objet: 5416
affectation interne, objet: 5365
affectation interne, objet: 5412

java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-9M3425)
Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02-384, mixed mode)
25/02/2013, 11h05
thelvin

Probablement l'optimisation JIT qui décide d'intervenir pendant la première boucle, voyant qu'il y a du code optimisable appelé tout le temps. Quelque chose de ce genre.
C'est pour ça que faire des micro-benchmarks, c'est une science en soi.
25/02/2013, 15h24
adiGuba

Citation:

Envoyé par questionneuse

effectivement le fait d'inverser l'ordre des boucles (donc de faire externe-interne-externe-interne au lieu de interne-externe-interne-externe) inverse les résultats c'est vraiment surprenant, j'ai du mal à comprendre...

Le compilateur se nomme "HotSpot", et ce n'est pas pour rien : cela signifie qu'il va détecter les portions de code très utilisé pour les optimiser. Par contre le niveau d'optimisation peut varier pour éviter de passer plus de temps à optimiser le code qu'à l'exécuter...

Il y a de forte chance que le premier type de boucle ne soit pas complètement optimisé, d'où la différence de résultat...

Ce qui est drôle aussi c'est que j'obtiens les mêmes résultats que toi, alors que ce n'était pas le cas auparavant. Je pensais que cela venais de la JVM mais ce n'est pas le cas.
Comme je ne suis pas sur le même poste cela doit venir d'une différence matérielle (une optimisation CPU peut-être ?).

Toutefois et malgré tout on parle d'une différence de moins de 3s sur 10 milliards d'itération ! Ramenée à une itération on tombe à 0,0000000003 s soit 300 nano-secondes...

C'est quelque chose de vraiment anecdotique, et on a déjà perdu plus de temps sur cette discussion qu'on n'en perdra dans toutes nos applications en utilisant une boucle interner ou externe !!!

a++