Discussion :

[Flaburgan]

Bonjour à tous,

Je me posais une question toute simple. J'ai pris l'habitude d'écrire le code suivant :

Code C# :

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

1
2
3
4
5
MonObjet objet;
for(//une boucle) {
 objet = new MonObjet();
 list.add(objet);
}

plutôt que

Code C# :

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

1
2
3
4
5
 
for(//une boucle) {
 MonObjet objet = new MonObjet();
 list.add(objet);
}

parce que j'avais l'impression que faire une seule déclaration simplifiait le travail du garbage collector. Est-ce le cas ? Parce que je me rends compte que mon code est moins lisible, et que la variable ainsi déclarée est accessible en dehors de la boucle, ce qui est bof...

Quelqu'un sait comment le garbage collector .Net fonctionne ?

(au passage, je me pose la même question pour JAVA, si ya des connaisseurs...)

[tomlev]

parce que j'avais l'impression que faire une seule déclaration simplifiait le travail du garbage collector. Est-ce le cas ?

Non, ça ne change rien pour le garbage collector. Le GC ne s'occupe pas des variables déclarées, seulement des instances d'objets.

Parce que je me rends compte que mon code est moins lisible, et que la variable ainsi déclarée est accessible en dehors de la boucle, ce qui est bof...

Effectivement c'est moins clair, et il est généralement recommandé de déclarer les variables le plus près possible de leur utilisation.

Quelqu'un sait comment le garbage collector .Net fonctionne ?

Euh, à peu près, mais c'est un peu vague comme question... c'est un vaste sujet.

En gros, le GC garde la trace des objets qui sont accessibles (car référencés par des objets accessibles). Quand un objet n'est plus accessible, il devient éligible au "ramassage" (garbage collection). Son finaliseur (destructeur) est exécuté s'il existe, et la mémoire utilisée par l'objet est libérée.

(au passage, je me pose la même question pour JAVA, si ya des connaisseurs...)

Pose la question dans le forum Java alors

[Flaburgan]

En fait, pour moi, ça aurait pu influencé le GC dans ce sens :
A chaque boucle, puisque j'ai une nouvelle déclaration, j'ai un nouvel espace mémoire réservé. J'ai un new qui est fait donc je place dans cet espace mémoire un nouveau pointeur vers mon nouvel objet. Le tour d'après, rebelote, donc mon ancien objet ET mon ancien espace déclaré doivent être supprimé.

Alors qu'avec le premier code, d'après mon interprétation, ça gardait l'espace mémoire pour le pointeur, et ça aidait le GC à voir que l'ancien objet n'était plus utilisé puisque j'effaçais l'ancien pointeur.

(en l'occurrence, je suis en train de me dire que puisque le l'ajoute à une liste, l'objet est bien toujours utilisé...)

[tomlev]

A chaque boucle, puisque j'ai une nouvelle déclaration, j'ai un nouvel espace mémoire réservé.

Non, c'est le même espace sur la pile qui est réutilisé. Il y a seulement une allocation de taille fixe, et comme c'est sur la pile le GC ne s'en occupe pas

J'ai un new qui est fait donc je place dans cet espace mémoire un nouveau pointeur vers mon nouvel objet. Le tour d'après, rebelote, donc mon ancien objet ET mon ancien espace déclaré doivent être supprimé.

L'ancien objet n'est pas supprimé, puisqu'il est toujours référencé par la liste. Et l'espace déclaré n'est libéré que quand tu sors de la méthode, mais de toutes façons la gestion de la pile n'est pas le travail du GC...

[DonQuiche]

Les deux codes produisent exactement la même séquence IL (bytecode).
Donc aucune différence. De toute façon, en IL, les emplacements des variables locales sont tous déclarés dans l'en-tête de la fonction.

Effectivement c'est moins clair, et il est généralement recommandé de déclarer les variables le plus près possible de leur utilisation.

Parce que cela permet dans certains au compilateur de réutiliser le même emplacement pour deux variables différentes (exemple : deux boucles for qui se suivent - pas imbriquées - chacune avec leur propre variable d'incrémentation de type int, le compilateur fusionnera les deux variables en une seule).

[tomlev]

Parce que cela permet dans certains au compilateur de réutiliser le même emplacement pour deux variables différentes (exemple : deux boucles for qui se suivent - pas imbriquées - chacune avec leur propre variable d'incrémentation de type int, le compilateur fusionnera les deux variables en une seule).

Ah, je connaissais pas cette optimisation... Mais de toutes façons, la meilleure lisibilité est déjà une raison suffisante pour suivre cette règle

[sisqo60]

Bonsoir,

A ma connaissance, il n'y a quasiment aucune différence, sauf comme tu dis que ta variable a un scope différent, elle est visible à l'extérieur de la boucle (pas vraiment intéressant quand on n'a pas vraiment besoin de cette variable plus bas) et que fondamentalement parlant, il y a allocation d'un pointeur à chaque itération de ta boucle mais si tu as coché la case optimiser le code dans les propriétés de ton projet, peut-être que le compilateur simplifiera et fera en sorte que ce pointeur soit réutilisé (enfin je ne mise jamais sur les optimisations que pourrais faire le compilateur C#).

Pour pousser un peu mémé dans les orties (j'adore cette expression )
tu pourrais écrire quelque chose du genre :

Code :

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

1
2
3
 
for (i=0;i<nombreInstances;i++)
    maListe.Add(new MonObjet());

Personnellement, je fais comme ça parce qu'il n'y a aucun intérêt à définir une variable intermédiaire alors que tu pourrais t'en passer.
Je sais que je chipote et que la différence en performances n'est pas énorme, mais c'est plus joli

Bon dév à tous

[DonQuiche]

A ma connaissance, il n'y a quasiment aucune différence, sauf comme tu dis que ta variable a un scope différent, elle est visible à l'extérieur de la boucle (pas vraiment intéressant quand on n'a pas vraiment besoin de cette variable plus bas) et que fondamentalement parlant, il y a allocation d'un pointeur à chaque itération de ta boucle

Pas tout à fait, il y a simplement réinitialisation de la variable à zéro (null) quand celle-ci a été déclarée à l'intérieur de la boucle (puisque toute allocation de variable implique mise à zéro).

Mais c'était bien vu tout de même et je confirme que le JIT optimise ça, donc pas de différence au final.

il n'y a aucun intérêt à définir une variable intermédiaire alors que tu pourrais t'en passer. Je sais que je chipote et que la différence en performances n'est pas énorme, mais c'est plus joli

La différence est là aussi nulle à mon avis, c'est typiquement le genre de choses optimisées, même si ce n'est qu'une supposition. Les variables locales n'existant pas en asm, le compilo profite généralement de la conversion en asm pour faire un peu de ménage.

[kheironn]

Oui, il faut penser qu'en IL beaucoup de code que l'on trouve plus lisible ou non donnera la même chose. de mémoire toutes les boucles deviennent un while, etc.

La question de la lisibilité reste surtout un point important pour le développeur.

[tomlev]

de mémoire toutes les boucles deviennent un while, etc.

Bah toutes les boucles deviennent des "goto" en fait (enfin des "branch" conditionnels pour être exact)

[kheironn]

Bah toutes les boucles deviennent des "goto" en fait (enfin des "branch" conditionnels pour être exact)

C'était un "de mémoire"... aloïse se rapproche !

Enfin tout ça pour dire, que l'on code plus pour nos petits yeux que pour la machine qui fait sa tambouille toute seule.