LES RÉFÉRENCES FAIBLES
oximoron
Messages postés
149
Date d'inscription
mercredi 23 juillet 2003
Statut
Membre
Dernière intervention
30 janvier 2009
-
2 oct. 2007 à 12:09
cs_coq Messages postés 6349 Date d'inscription samedi 1 juin 2002 Statut Membre Dernière intervention 2 août 2014 - 7 oct. 2007 à 09:38
cs_coq Messages postés 6349 Date d'inscription samedi 1 juin 2002 Statut Membre Dernière intervention 2 août 2014 - 7 oct. 2007 à 09:38
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/44260-les-references-faibles
https://codes-sources.commentcamarche.net/source/44260-les-references-faibles
7 oct. 2007 à 09:38
7 oct. 2007 à 09:37
Il n'y a à ma connaissance aucun mécanisme de compression.
Et fait attention à ce que tu utilises pour tes mesures : http://www.itwriting.com/dotnetmem.php
7 oct. 2007 à 09:34
Non, il ne touche pas au disque."
Je voulais bien sûr dire mémoire et pas disque, je pensais mémoire mais j'ai écris disque :p
7 oct. 2007 à 06:00
Ainsi, un développeur qui garde plein de références inutiles vers des instances de classes va pourrir la mémoire, sans que le garbage collector ne puisse rien y faire...
Enfin toujours est-il que je ne pense pas pouvoir expliquer dans les moindres détails les rouges de ce mécanisme, car il semble assez complexe.
Pour preuve, j'ai récement écrit un petit outil de revue de code (le langage de ces fichiers était du nsdk). Après parsing, j'avais une hiérarchie d'objets : un objet "fichier nsdk" contient des descriptions de segments, des constantes, ou des méthodes, un objet "méthode" contient des variables, ect... je ne vais pas détailler ici l'ensemble des objets, mais toujours est-il que le résultat en mémoire était assez important : et je ne pouvais rien libérer car l'objet de ma revue de code était de voir si certaines méthodes dans plusieurs fichiers n'étaient pas suffisamment identiques pour être mutualisées. Toujours est-il qu'au cours du chargement des fichiers, la jauge mémoire grimpait, puis descendait un peu (???) puis continuait à monter, puis redescendait un peu... alors qu'aucune libération mémoire n'était faite pendant ce temps (bien au contraire). Le garbage collector ou le framework font-ils de la compression des données en mémoire si ça se gate ? Bref, c'est un phénomène assez bizarre (que j'avais déjà eu l'occasion de rencontrer, et qui montre, à mon avis, que cette gestion de la mémoire n'est pas si anodine que ça...
enfin en conclusion ; le garbage collector, c'est bien, mais faut quand même faire un minimum gaffe à ce qu'on fait ^^
6 oct. 2007 à 18:13
Non, il ne touche pas au disque.
"J'ai envie de dire, connaitre son fonctionnement est bon pour la culture générale, mais finallement, le principal, c'est qu'il fasse bien son travail"
Oui et non ^^ : le problème en ne connaissant pas un minimum son fonctionnement, c'est que la personne à tendance à le prendre pour la solution magique lui permettant de ne plus se soucier du fait qu'un code alloue de la mémoire à tour de bras alors qu'une autre façon de faire l'aurait éviter : si le risque de fuite est écarté, celui de l'impact sur les performances ne l'est pas : le GC qui libère est un GC qui consomme du temps (le problème de la concaténarion de chaines en est un exemple courant)
.
2 oct. 2007 à 14:32
D'ailleurs, je ne sais pas si tu as remarqué, mais si tu laisses l'appli en plan quelques minutes sur une image "A", et que tu cliques sur un autre image "B", alors il y a un rechargement depuis le disque pour "B". Si tu reviens tout de suite après sur "B", il n'y a pas de rechargement en mémoire, tout simplement parceque la référence vers l'obet bmp était maintenue par... le PictureBox ! Hé oui ;-)
2 oct. 2007 à 13:07
Le fonctionnement du garbage collector est assez complexe, mais ce qui certain, c'est qu'il ne dispose pas des ressources tant qu'il reste une référence dessus (et encore heureux...!)
2 oct. 2007 à 12:09
Est ce que ce code marche avec le framework 1.1 ?
Autre question: c'est le garbage collector qui s'occupe de liberer de l'espace disque. Si j'ai une collection d'images en mémoire il qu'il doit liberer de la mémoire, sur quoi se base t'il pour supprimer une image ? la fréquence d'utilisation, au hasard, ... ?