Discussion :

[kwiskas56]

Bonjour,

Mon application gère mal le vidage de la mémoire qui augmente a chaque ouverture de fenêtre, voici comment ce comporte l application :

- Dans ma form principal je fais un show d'une fenêtre et quand cette fenêtre est fermée un handler " fermerform(Sender = MaFenetre) " est executer.

A la fin de cet handler je fais un Sender.dispose et sender = nothing

L'application peut être exécuter plus de 100 fois sur un même poste (TSE)

Mémoire utilisée :
- Au lancement (avec le menu) 50 Mo -> 1 fenêtre ouverte 65 Mo ->
Retour au menu 60 Mo -> 1 fenêtre ouverte 70 Mo ->
Retour au menu 65 Mo -> 1 fenêtre ouverte 75 Mo -> ...

Auriez vous une méthode qui va me permettre de vider la mémoire utilisée ?

merci

[tomlev]

S'il ne reste aucune référence vers les fenêtres en question, la mémoire sera automatiquement récupérée quand le système l'estimera nécessaire. Tu peux forcer la collecte de la mémoire inutilisée en appelant GC.Collect (mais attention de ne pas en abuser, c'est gourmand en termes de performance...)

[Pol63]

nous on a un thread dans l'appli qui appelle gc.collect toutes les 5min et y a pas soucis spéciaux, meme si en théorie ca se passe très bien tout seul et que là c'est un peu extremiste
(appli en route 24/24 7/7)

sinon attention à bien compiler en mode release et pas en mode debug

[tomlev]

nous on a un thread dans l'appli qui appelle gc.collect toutes les 5min et y a pas soucis spéciaux

Toutes les 5 minutes, c'est pas ce que j'appelle "en abuser"

sinon attention à bien compiler en mode release et pas en mode debug

Ca change quelque chose par rapport à GC.Collect ?

[Gold Bug]

Si le GC ne collecte pas, c'est qu'il n'y a rien à collecter
En gros, il y a un endroit où tu fais des allocations mémoire (même si cette allocation se fait "à ton insu" par le framework) que tu ne libères pas par la suite.

Tu devrais nous en dire un peu plus sur ce que fais ton application : accès à des fichiers, déclenchement de Threads asynchrones, dessins avec les objets du Namespace System.Drawing...

[tomlev]

Si le GC ne collecte pas, c'est qu'il n'y a rien à collecter

Pas forcément... le GC ne tourne pas en permanence. Si un objet n'a plus aucune référence qui pointe dessus, en général il n'est pas immédiatement collecté par le GC

[Gold Bug]

Pas forcément... le GC ne tourne pas en permanence. Si un objet n'a plus aucune référence qui pointe dessus, en général il n'est pas immédiatement collecté par le GC

Oui, je connais assez bien le fonctionnement du GC, je me le suis farci en long et en large en formation.

Mais là visiblement, son problème se déroule à l'échelle d'une journée, donc je ne pense pas qu'il soit directement lié au GC.

[Pol63]

Ca change quelque chose par rapport à GC.Collect ?

oui et non
mais sur la mémoire prise par l'appli oui

en mode debug, le compilateur garde des instances de tout
on a fait des tests chez un client sans faire gaffe qu'on était en mode debug et l'appli crashait au bout de 2 jours avec outofmemory
pour chercher on avait fait un test :instancier une classe de 2 lignes héritant de component dans une boucle avec un using pour le dispose, et ca crashait très rapidement
au final je suis tombé sur un article de mcirosoft expliquant les différences en mode debug et release

d'ailleurs en mode debug, avec un point d'arret dans le catch par exemple, on peut connaitre la valeur des variables de sub qui sont hors portée, en mode release, vs ne donne pas la valeur

[tomlev]

oui et non
mais sur la mémoire prise par l'appli oui

en mode debug, le compilateur garde des instances de tout
on a fait des tests chez un client sans faire gaffe qu'on était en mode debug et l'appli crashait au bout de 2 jours avec outofmemory
pour chercher on avait fait un test :instancier une classe de 2 lignes héritant de component dans une boucle avec un using pour le dispose, et ca crashait très rapidement
au final je suis tombé sur un article de mcirosoft expliquant les différences en mode debug et release

d'ailleurs en mode debug, avec un point d'arret dans le catch par exemple, on peut connaitre la valeur des variables de sub qui sont hors portée, en mode release, vs ne donne pas la valeur

OK merci... c'est bon à savoir !

[Pol63]

et dans l'article de microsoft, ils disent que c'est interdit de distribuer un programme en mode debug

[tomlev]

et dans l'article de microsoft, ils disent que c'est interdit de distribuer un programme en mode debug

interdit ?! qu'est-ce que ça peut leur faire ?