Discussion :

[ppphil]

Bonjour,
J'ai de la peine à comprendre ou plutôt à accepter comment se gère la mémoire des programmes dotnet.

Soit le code suivant :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
    List<string>() list = new List<string>();
 
    private void button3_Click(object sender, EventArgs e)
    {
      string s;
 
      using (StreamReader sr = new StreamReader("C:\\temp\\texte.txt"))
      {
        s = sr.ReadToEnd();
        for (int i = 0; i < 1000000; i++)
        {
          list.Add(s);
        }
        sr.Close();
      }
    }
 
    private void button4_Click(object sender, EventArgs e)
    {
      list.Clear();
      list.Add("");
      //GC.Collect();
    }

Le fichier chargé est un fichier de 5 Mo.
Avec le code du bouton 3 je charge la mémoire.
Avec le code du bouton 4 je vide ma liste donc théoriquement la mémoire.

Dans le task manager, la quantité de mémoire utilisée ne diminue pas, une fois la liste vidée, si je ne fais pas le Collect du GC.
Et quand je le fais, parfois la mémoire utilisée retombe à sa valeur initiale, parfois ne redescend que très peu.

Si je lance plusieurs fois mon soft et que je charge au max la mémoire puis que je vide ma liste, une fois toute la mémoire de mon ordi utilisée, petit-à-petit, de la mémoire se libère sur les différents process du même soft.

Quand ma mémoire est utilisée à 90% environ mon ordi rame tout de même.
Et pourtant il ne s'agit pas de mémoire utilisée mais de mémoire disponible dans le GC.

De plus, pour contrôler le bon fonctionnement d'un soft, il est donc impossible de savoir quelle somme de mémoire il utilise réellement.

Et certains clients gueulent que mes softs sont trop gourmands......

D'où la question :
Quelle est la bonne pratique afin d'avoir dans le task manager, la somme de mémoire réellement utilisée par un soft dotnet ?

[tomlev]

Le truc, c'est que ton programme réserve une certaine quantité de mémoire, qu'il conserve tant que l'OS n'en a pas besoin. Si tu fais un GC.Collect, ça va effectivement ramasser les objets inutilisés, et donc libérer de l'espace dans la mémoire réservée par ton programme. Mais cette mémoire ne sera pas nécessairement rendue au système s'il n'en a pas besoin...

En fait c'est assez complexe d'analyser exactement ce qui se passe au niveau de la gestion mémoire, surtout que les colonnes affichées par défaut dans le task manager ne sont pas forcément pertinentes. J'avais vu un article qui expliquait pas mal tous ces trucs là, mais pour l'instant je le retrouve pas...

[ppphil]

Je te remercie déjà pour cette réponse.
Si tu as des nouvelles ou si tu retrouves ton article je suis preneur.

En attendant, bonne soirée

[Arnard]

ya la faq qui en parle brièvement : http://dotnet.developpez.com/faq/csh...#netfx_misc_gc et http://dotnet.developpez.com/faq/asp...server#syst_gc


Mais la libération n'est pas automatique, cependant, en laissant le programme vivre, tu dois obtenir quelque chose de régulier, sinon tu as des fuites mémoires. Quel est le type de ton application ?

[ppphil]

Quel est le type de ton application ?

Le bout de code présenté ci-dessus par exemple...

[tomlev]

Voilà, j'ai retrouvé l'article (en anglais) :
http://blogs.msdn.com/b/kirillosenko...10-part-2.aspx
Il explique pas mal les différents indicateurs d'utilisation mémoire

En cherchant je suis aussi tombé sur celui-ci qui a l'air intéressant aussi :
http://www.itwriting.com/dotnetmem.php

[Arnard]

L'interface graphique est winform ou WPF ? Y a-t-il d'autres éléments de traitement ? On s'est retrouvé cette année à faire la chasse aux fuites de mémoire, sachant que la plus grosse source d'ennui étaient les événements avec les références nulles non désabonnées et les Dictionary de wpf. Ya ptete moyen de t'orienter sur quelques éléments permettant d'améliorer ce fait. Après faut faire piger au client que la mémoire elle redescend pas automatiquement, et pour avoir vécu, c'est dur...

[ppphil]

L'interface graphique est winform ou WPF ?

C'est du winform

...sachant que la plus grosse source d'ennui étaient les événements avec les références nulles non désabonnées et les Dictionary de wpf. Ya ptete moyen de t'orienter sur quelques éléments permettant d'améliorer ce fait.

D'un côté j'avais un vieux soft dans lequel je n'utilisais pas de using pour les streams en tous genres. J'ai fais quelques corrections.
Mais avec le bout de code présenté dans mon post, je me suis posé toutes ces questions.

Après faut faire piger au client que la mémoire elle redescend pas automatiquement, et pour avoir vécu, c'est dur...

Si ce n'étaient pas eux qui contribuaient à créer notre salaire, au moins on pourrait leur taper un peu dessus

Merci pour tes docs tomlev !!!

[Arnard]

Là d'un point de vue mémoire c'est propre, tu ne pourras pas faire plus, pour le morceau de code affiché en tout cas...

Par contre ton traitement de parse se fait dans le thread de l'UI ? Les fichiers à lire ne sont pas trop gros à freezer l'interface ?

[ppphil]

Non, non t'inquiète pas
Et ce n'est qu'un soft de test.