Discussion :

[Veler]

Bonjour,

J'ai un projet qui consomme en temps normal 90Mo de RAM.
J'ai un Backgroundworker qui, à la suite d'accès au disque dur, de calcul, de conversion... fait monter la mémoire à 150Mo.
Le problème est que malgré qu'à la fin de son exécution, je vide toute les variables et utilise tous les "Dispose()" possible, la mémoire reste à 150Mo.
Bien entendu, si je réexécute le BackgroundWorker, la mémoire monte cette fois-ci à 210Mo, et ainsi de suite.

Existe-t-il un moyen efficace de libérer la mémoire?

Merci d'avance

[Nathanael Marchand]

C'est pas parceque tu appelles Dispose que la mémoire est libérée!
La mémoire est libérée lorsque le système estime qu'il y a besoin.

[Veler]

Bonjour,

D'accord, à ce niveau là j'ai tort
Mais, juste un exemple : Visual Studio, quand on ferme une solution, il arrive à ce libérer de la mémoire emmagasiné. Certes pas à 100%, mais pas loin de 70% à 80% tout de même.
J'aimerais bien trouver l'astuce en fait

Merci =)

[Arnard]

Il est possible qu'il force le passage du garbage collector, via GC.Collect(); mais il n'est pas recommandé de l'utiliser comme ça, sans une connaissance approfondie du système .Net.

[Nathanael Marchand]

Visual Studio n'est peut être pas le meilleur exemple car il n'est pas managé (ou pas entièrement)
Il faut savoir que faire passer le GC pour collecter ca a un cout non négligeable et que du coup vider de la mémoire pour vider de la mémoire (même si y'en a pas besoin) dégrade les perfs.

[Veler]

Bonjour,

D'accord, je vais aller me renseigner à tout hasard =)

Merci ^^ Si vous avez autre chose n'hésitez pas

[Veler]

Re-bonjour,

Alors voila, je me suis renseigné sur le fameux System.GC. J'ai fait différent teste et ai surtout veillé à ce que la partie gourmande en mémoire soit isolé, qu'il n'y ai plus de référence à celle-ci de possible.
Alors soit j'ai oublié un endroit et il y a toujours une référence (j'ai même fait un Obj = Nothing), soit le problème vient d'ailleurs, car la mémoire ne se libère toujours pas avec GC.Collect et ses dérivé =/

Une idée?

[Arnard]

Ce qui t'inquiète, c'est que chaque accès fasse croître la mémoire de 60Mo, de manière infinie ?

[Veler]

Bonjour,

Voila, c'est ça, et du coup si on utilise cette fonction (qui sera utilisé très régulièrement) plus de 20 fois sans redémarrer le programme on atteindra 1,2Go. Je sais bien qu'aujourd'hui les PC ont beaucoup de RAM, mais sur des ultra portable ou des PC infesté de virus et de spyware, ça va peut-être pas passer aussi facilement

Alors, j'ai fait quelques recherches : un coup de FxCop, mais rien de très spécial, et puis j'ai fait un coup de CLR Profiler, pour déterminer qu'est-ce qui reste en mémoire indéfiniment :

Dans ce Backgroundworker, je charge des fichier XAML dans un System.Activities.Presentation.WorkflowDesigner ancré dans un ElementHost (pour ensuite faire des manipulations en arrière plan évidemment). Et pour des raisons techniques, lors du chargement du workflow je doit passer par un Délégué pour que ça se fasse sur le thread principale (sinon ça ne fonctionne pas, on a une exception).
Mais pourtant j'ai bien fait attention de Disposer chaque designer avant de passer au suivant.

Le problème viendrait-il de ce fameux designer chargé? Apparemment c'est ça qui reste en mémoire.

[Arnard]

Même si tu disposes, la mémoire ne redescendra pas forcément de suite, mais quand Windows en aura besoin. Essaie de lancer ton système plusieurs fois (automatise), et mesure l'évolution de la mémoire en début/fin d'opération. Tu devrais observer une stagnation voire une chute à certains moments.

[DonQuiche]

Essaye donc d'ajouter les deux lignes suivantes :

Code :

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

1
2
GC.WaitForPendingFinalizers();
GC.Collect();

Si la mémoire n'est toujours pas libérée, alors tu as un problème : ressources non-managées pas nettoyées, références circulaires, etc... CLRProfiler peut t'aider à y voir plus clair dans ce genre de cas. Pour les versions récentes (>= 2.0 je crois) du framework, fais-toi un .bat comme suit :

Code :

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

1
2
set COMPLUS_ProfAPI_ProfilerCompatibilitySetting=EnableV2Profiler
CLRProfiler.exe

[Veler]

Bonjour,

je vais essayer tout ça.
Par hasard, est-ce que des variables déclarés non pas dans les fonctions mais dans la Class en elle-même jouent-t-elles sur la mémoire?

[Arnard]

bien sûr, tout dépend du nombre et du poids de chaque

[Veler]

Bonjour,

Alors suite aux différents testes, j'ai put constaté que le designer Workflow est bien l'élément qui reste en mémoire et qui en consomme beaucoup. Pourtant, comme les autres objets, je l'ai vidé de son contenu. J'ai même essayé de lui implémenter l'interface IDisposable pour le vider mais ça ne change rien
La je ne sais plus trop ou donner de la tête, le GC.Collect ne fonctionne pas ici. J'imagine donc que le designer n'est pas collecté, sûrement à cause d'un problème de référence?