Destruction d'objets Dispose() Garbage Collector

Bonjour,

Je cherche depuis pas mal de temps une méthode fiable pour détruire les objets de façon certaine.
Pour fermer une "form", j'appelle la méthode Close() puis dans l'évènement FormClosed, j'appelle la méthode Dispose() pour toutes les ressources non managées et pour la form elle-même.

Si je fais un recherche des contrôles qui ne seraient pas détruits, la recherche me dit bien que tous les objets sont bien détruits et apparamment déréférencés.

Le problème est qu'en ouvrant ClrProfiler et en analysant via le gestionnaire de taches : il reste toujours quelques éléments de la form (ClrProfiler) et la mémoire n'est pas bien libérée.
J'ai l'impression que le ramasse-miettes (Garbage Collector) est bien paresseux.

J'ai donc essayé ce code

Code:

---

1 2 3 4 5

Try System.GC.Collect() System.GC.WaitForPendingFinalizers() Catch ex As Exception End Try

---

Le "nettoyage" est immédiat et l'occupation mémoire reste contenue à chaque ouverture et fermeture de la "form".
Je n'ai aucun retour d'erreur et le programme se comporte bien.

Malheureusement, en parcourant le web, il est dit partout qu'il NE FAUT PAS utiliser le GC et le laisser travailler seul.

Pour une form "lourde" de mon logiciel, si je n'utilise pas ces quatres lignes, j'ai une augmentation régulière de l'occupation mémoire et pourant je suis sur d'avoir libéré toutes les ressources non "managées" les bitmaps par exemple.

Un éclaircissement serait le bienvenu.

Merci d'avance.

ca peut être lié spécifiquement au code

par exemple si tu as une variable bitmap dont tu remplaces le contenu plusieurs fois et que tu disposes sur le form closed, les instances précédemment stockées ici ne sont pas disposées (faire le dispose avant chaque remplissage de l'ancienne valeur si elle existe par exemple)

quand on dispose un control, toute la hiérrarchie des enfants est disposée
si tu avais remove un control pour faire un truc il n'est plus dans le lien de parenté et ne sera pas disposé

etc...


le but du GC n'est pas de vider la mémoire à tout prix et le plus rapidement possible, il passe quand il y a besoin, au final c'est surement moins gourmand
de nos jours les pcs ont plusieurs Go de ram, qu'une appli prenne 50 ou 250 Mo de ram ca ne change rien pour windows et l'utilisateur
normalement on voit une diminution cyclique de la ram au bout d'un certain usage, et si une appli a besoin de ram et qu'il n'y en a plus, le gc sera appelé donc pas de soucis non plus
par contre ce fonctionnement va bien si on gère la mémoire dans l'appli
une boucle qui fait des new bitmap et l'appli crash rapidement

le using / end using est pratique aussi, il garanti l'appel du dispose même en cas de sortie de bloc comme une exception

dans clr profiler tu dois pouvoir trouver les types des choses qui restent pour trouver la "fuite"


concernant le GC.Collect s'il est accessible ca doit bien être pour une raison :D
nous on a fait un thread qui gc.collect et thread.sleep(5 minutes) en boucle
on a fait ca au début parce qu'on avait des soucis et surement pas tout compris, mais vu que ca ne dérange pas plus que ca on l'a laissé ...

Re,

Merci pour la réactivité et la qualité de la réponse !

Pour les bitmap, par exemple, lorsque je ferme la form la ressource est libérée.
La variable bitmap est globale mais j'effectue un dispose() suivi d'une affectation à Nothing même si je dois la réutiliser par la suite.
Sinon, de toute façon, c'est memory leak à tous les coups ! avec ou sans GC.

Justement pour un exemple de fuite, sur un splashscreen très simple, j'ai essayé diverses méthodes sans résultats probants pour la libération : il n'y a qu'une image en background et des label.
Même si je fais un dispose () manuel de tous les contrôles (je ne devrais pas avoir besoin de le faire Me.dispose est suffisant mais j'ai quand même essayé) , il y a des "restes" de label référencés dans ClrProfiler.
La référence à ces label n'existent que dans la form.
L'occupation est minime (20 K) après libération mais il reste des références dans ClrProfiler ?
J'aimerai comprendre pourquoi ?

Pour Using et end using, je verrai comment modifier mes lignes mais ce n'est pas simple sur une form qui a 15000 lignes de code.

Donc pour résumer, le GC bosse quand il veut ou quand il est pressant de libérer et à son rythme.

Pour l'appel du GC, je vois que tu l'utilises avec un thread dédié mais y-a t-il contre-indication à utiliser l'appel à collect à chaque sortie de form ?
Car si c'est possible sans risque de pénaliser Windows ou le soft, le problème serait résolu.

Citation:

---

Envoyé par Pascal_F

La variable bitmap est globale mais j'effectue un dispose() suivi d'une affectation à Nothing même si je dois la réutiliser par la suite.

---

la mise à nothing est automatique en sortie de bloc, les variables ne sont d'ailleurs pas utilisables hors du bloc
concernant les variables de classes, elles sont mises à nothing sur le finalize si je me rappelle bien
et donc le GC peut intervenir sur des variables non référencées par des choses "vivantes"
le finalize c'est le truc que le GC appelle, sur les classes implémentant IDisposable, le dispose(false) est appelé à ce moment là, ce qui permet en théorie d'éviter tout fuite réelle

Citation:

---

Envoyé par Pascal_F

Sinon, de toute façon, c'est memory leak à tous les coups ! avec ou sans GC.

---

oui et non je pense, cf au dessus
le truc bien pour les fuites c'est addhandler sans removehandler

Citation:

---

Envoyé par Pascal_F

L'occupation est minime (20 K) après libération mais il reste des références dans ClrProfiler ?
J'aimerai comprendre pourquoi ?

---

moi aussi :D

Citation:

---

Envoyé par Pascal_F

Pour Using et end using, je verrai

---

pour le coup c'est le truc anti fuite
c'est quasiment indispensable, ca équivaut à un try finally, les classes de connexions aux données par exemple dans le dispose font le .close sur la connexion
sur un code de type

Code:

---

1 2 3 4 5 6

try conn.open cmd.executenonquery conn.dispos catch ...

---

ici en cas d'erreur la connexion reste ouverte, on peut s'en sortir avec d'autres méthodes que le using mais le using est quand même plus pratique

Code:

---

1 2 3 4 5 6 7

try using conn conn.open cmd.executenonquery end using catch ...

---

là même dans le catch conn.dispose sera appelé et donc la connexion fermée

Citation:

---

Envoyé par Pascal_F

ce n'est pas simple sur une form qui a 15000 lignes de code.

---

au dessus de 1000 lignes de code dans un form c'est un soucis de conception ou d'utilisation de .net
si tu veux je peux jeter un oeil à ton code pour te dire ce qu'il y a de raté

Citation:

---

Envoyé par Pascal_F

Donc pour résumer, le GC bosse quand il veut ou quand il est pressant de libérer et à son rythme.

---

c'est ça

Citation:

---

Envoyé par Pascal_F

Pour l'appel du GC, je vois que tu l'utilises avec un thread dédié mais y-a t-il contre-indication à utiliser l'appel à collect à chaque sortie de form ?
Car si c'est possible sans risque de pénaliser Windows ou le soft, le problème serait résolu.

---

ca ne peut pas pénaliser windows, ca ne peut pénaliser que ton appli
normalement ca peut être bloquant, c'est pour ca qu'on le fait sur un thread séparé (bien qu'il parrait que de toute facon ca verrouille tous les threads), sur une petite appli et un gros pc ca ne doit pas se voir
après si ton appli n'est pas censé tourner h24 et qu'elle est petite normalement tu n'as pas besoin d'appeler gc.collect, à part pour voir baisser la ram prise, mais là on tombe dans le psychologique :D il faut surtout se dire qu'on est plus y a vingt an ou le moindre logiciel devait être optimisé niveau ram

L'application développée est du domaine de la phsyique appliquée (conditionnement de l'air humide).
La page principale accueille au lancement un diagramme complexe qui est en fond de page ( ce fond de page n'est pas réactualisé sauf si il faut redessiner le diagramme dans certains cas; le bitmap est bien réinitialisé et il n'y a pas de problème de fuite de ce coté).

Pour réaliser les évolutions sur ce diagramme, j'ai implémenter 12 modules différents qui sont regroupés chacun sur des panels qui sont cachés ou visibles suivant les besoins. Les panels acceuillent des contrôles (environ 350) qui sont actualisés à chaque action.

Ce choix me permet :

- de m'affranchir d'une gestion entre la fenêtre de fond qui doit être réactive ( évènements mousedown et mousemove) et l'affichage de l'interface pour entrer ou modifier des paramètres. Si j'avais choisis l'option de créer pour chaque module une fenêtre, il fallait à chaque fois l'intialiser avec les paramètres en cours. Il aurait fallu plus de code au total à chaque réinitialisation et ouverture d'une form secondaire

- de réactualiser en fond de tâche chaque panel même si il n'est pas visible (action d'un module sur l'autre)

- de gérer aussi facilement les fonctions Undo et redo à partir d'un memorystream sauvant les proprités principales des contrôles et le contenu des variables globales.

- de sauver les différentes propriétés des paramètres dans ces panel dans un fichier et de les retrouver simplement à l'ouverture du fichier sans avoir à jongler avec les différents contrôles.

Dans cette page, comme il y a beaucoup de contrôles,il y a aussi beaucoup d'évènements à gérer : j'ai regroupé les évènements par type pour diminuer la répétion des évènements équivalents et le nombre de lignes.

Mais , il y a aussi une très grande quantité d'équations pour le calcul.
C'est ce qui explique la grande quantité de lignes.
Trop de Sub, pour scinder, ralentit l'éxécution du logiciel et la gestion est plus compliquée.



J'ai quatre évènements dans l'ordre Removehandler puis AddHandler ( pour éviter des erreurs de stack : boucle infinie sur un texchanged par exemple).
J'enlève l'évènement pour actualiser puis je le réintègre.
Sur tes conseils, j'ai rajouté 4 Removehandler à la fermeture de la form.

Je vais donc laisser le GC.collect que pour la page principale et ne pas l'utiliser pour le reste.
Le logiciel ne tourne pas 24/24 et l'utilisateur ne s'amuse pas à ouvrir successivement la page principale.

une réponse à l'américaine :

bullshit

(ceci n'est pas péjoratif)

Bonjour,

Je vais essayer mais je ne vois pas en quoi mettre un DoEvents et répéter la même action pour le GC ferait avancer le "schmilblick".
De plus, cela n'interesse personne de savoir qu'il y eu un problème de nettoyage dans le logiciel (Msbox version VB6 en Vb net c'est messagebox ...)

Pour le problème de référencement lié au déchargement des objets d'une page (post plus haut), j'avais dis que je ne comprenais pas pourquoi il y avait des "restes" après collecte.
J'ai la solution mais pas l'explication du problème : j'ai créé une routine à part qui gère à chaque fermeture d'une page (ou form) la mise à nothing de cette page déchargée. Il n'y a plus de références à cette page et le problème de ce coté est réglé.

Par contre, les chaînes de caractéres restent invariablement en mémoire ("immutable") et c'est dommage qu'i n'y ait rien pour les "nettoyer".
Si j'utilise l'api RtlZeroMemory, je ne peux plus référencer de nouveau la chaîne de caractères.

Bon,

Cela a été rapide : j'ai essayé DoEvents ne résoud absolument pas le problème.
Répeter les mêmes commandes relatives au GC : pourquoi faire ? Si le GC a encore des références ce n'est pas en lui demandant plusieurs fois de faire la même chose que le résultat sera la.

Donc à part la mise à nothing des form déchargées, je n'ai pas encore pu trouvé une solution viable pour éliminer ce qui reste en mémoire cache : c'est peut-être voulu par Microsoft pour diminuer le temps de compilation en cas de réutilisation de la page; je ne sais pas !
Il reste toujours des handles, eventhandler ... , des string ... qui ne veulent pas tirer leurs révérences.

Il y avait bien une solution en utilisant une API "SetProcessWorkingSetSize" mais le problème est déplacé : pratiquement plus d'occupation en mémoire vive mais tout bascule sur le virtuel .... Ce n'est donc pas une bonne solution.

pour en revenir à la problématique de départ, tu as constaté une fuite de plus de 100 Mo ? une augmentation rapide ou jusqu'à un crash ?

et il faut arrêter de faire des hypothèses, si tu veux savoir comment ca fonctionne il faut se documenter sur le gc, il y a des articles sur le net
(il n'y a pas plusieurs compilation par "page" par exemple)

Re,

Merci pour ta réponse.

Non, le niveau d'utilisation se stabilise en appelant de temps en temps le GC et j'ai fait le test de "memory leak" il n'y a pas de problèmes ou d'alertes.
Pas de crash ou d'Out of memory".

En fait, je voulais chercher à comprendre et à optimiser au maximum.

D'ailleurs, j'ai arrêté de chercher car je ne peux pas optimiser plus le déchargement des objets ou alors il faudrait que je décharge manuellement ce qui reste en mémoire via les infos (GC.handle( object, GCHanldeType.pinned) ce qui rendrait le code en cours plus lourd qu'il ne l'est.

J'ai peut-être une piste sérieuse : j'utilisais au départ le NetFrameWorks 2.0 largement suffisant pour ce que j'ai à faire mais j'ai remarqué que sous Windows 8 et NetFrameworks 4.0 la collecte est plus efficace et l'occupation mémoire bien plus réduite (même en 64 bits). Il faut croire que les procédures ont été optimisées depuis.
Mais je n'ai pas encore de recul suffisant pour affirmer ou infirmer ce que j'ai dit.

Citation:

---

Envoyé par Pascal_F

En fait, je voulais chercher à comprendre et à optimiser au maximum.

---

une optimisation est déjà présente dans le GC et cette optimisation fait que la ram n'est pas libérée tout de suite
il y a 15 ans on libérait la ram tout de suite car il y en avait très peu, ce n'est plus le cas de nos jours, qu'une appli prenne 50 et 80Mo de ram ne change rien ; et libérer la mémoire souvent est au final plus couteux niveau performances, donc l'optimisation est que ca n'est pas fait en continue

chercher à aller contre n'est donc pas forcément une bonne idée

Bonjour.

Un petit ajout à tout ce qu'a très justement dit Pol63 : il faut bien comprendre les inconvénients de l'appel manuel à GC.Collect :
* Gel de l'appli pendant ce temps (déjà mentionné).

* Gaspillage du CPU (tous les objets racines seront passés à chaque fois en revue, y compris ceux qui ne seront pas nettoyés, et les trois générations sont passées en revue contre une seule en général avec un passage automatique).

* Augmentation du nombre d'objets en génération 2 (le génération d'un objet est incrémentée à chaque passage du GC). Du coup la G2 va être polluée par des objets éphémères désormais morts et qui ne seront généralement pas nettoyés par les passages automatiques du GC. Cela va éparpiller les données vivantes dans la mémoire, réduisant donc les performances lors de leurs accès. Et cet état perdurera jusqu'à ce qu'une passe manuelle du GC soit réalisée ou que le système manque sévèrement de mémoire.

Re,

Merci des informations sur le GC.

En fait, je ne fais appel au GC qu'une fois sur deux et seulement à la fermeture des "forms" jamais pendant l'exécution du code des fenêtres.
Pendant l'éxécution, je n'ai pas du tout d'augmentation d'occupation mémoire au contraire même le GC fait son boulot tout seul.

Par contre, comme j'ai une fenêtre principale très "lourde" elle a tendance lorsque je la ferme et l'ouvre plusieurs fois de suite à augmenter en mémoire même si il y a stabilisation au bout d'un moment.

C'est pourquoi, ma routine met à nothing la fenêtre fermée pour être sur de bien décharger les objets : j'ai fait un essai avec Memory Profiler (Si je ne fais qu'un close ou dispose, le déchargement est incomplet et j'ai des avertissements pour un mauvais déchargement.)
Puis, je fais appel au GC qu'à la deuxième fermeture de fenêtre.
Donc le GC ne ralentit pas vraiment l'exécution car il n'intervient que lorsque l'on ferme une fenêtre (donc pas trop d'impact sur la performance).

Sans appel au GC, la ram débute à 15 Mo puis à l'ouverture/fermeture successive de la fenêtre principale du fichier projet monte jusqu'à 130 Mo maximum et se stabilise en redescendant de temps en temps à 85 Mo.
Avec appel du GC une fois sur deux, sans ralentissement notable à la fermeture, le minimum est de l'ordre de 55 à 60 Mo et le maximum va jusqu'à 100 Mo.

Peut-être faudrait-il ne pas faire appel manuellement au GC et laisser la mémoire monter puisqu'en faisant des tests avec Memory profiler je n'ai pas d'avertissement relatif à une fuite mémoire quelconque ?
Je ne suis pas un pro et j'ai du mal à prendre une décision !

si ton appli stagne à 60 avec collect et qu'elle ne monte pas au dessus de 300 sans collect, je pense que tu peux retirer le collect

certes tu gagnes en ram, mais tu perds en processeur, et sur un pc portable sur batterie tu perds de l'autonomie par exemple
et si une autre appli a besoin de la ram que tu occupes pour rien, elle la demandera à windows, qui lui appellera le collect de ton appli à ce moment là, donc la ram que tu consommes en trop ne dérange personne

Re,

Ok, je vais suivre vos conseils car la ram ne dépasse pas 150 Mo dans tous les cas (45 ouvertures/fermetures succesives de la page principale de projet) et redescend régulièrement à 90 Mo.