La lecture du flux PackagePart ne libère pas la mémoire

Question

Dans notre application, nous lisons un fichier XPS à l'aide de la classe System.IO.Packaging.Package. Lorsque nous lisons à partir d'un flux d'un packagePart, nous pouvons voir à partir du Gestionnaire des tâches que la consommation de mémoire de l'application augmente. Cependant, lorsque la lecture est terminée, la consommation de mémoire ne revient pas à ce qu'elle était avant de lire le flux. Pour illustrer le problème, j'ai écrit un exemple de code simple que vous pouvez utiliser dans une application wpf autonome.

public partial class Window1 : Window 
{ 
     public Window1() 
     { 
      InitializeComponent(); 

      _package = Package.Open(@"c:\test\1000pages.xps", FileMode.Open, FileAccess.ReadWrite, FileShare.None); 

     } 

     private void ReadPackage() 
     { 
      foreach (PackagePart part in _package.GetParts()) 
      { 
       using (Stream partStream = part.GetStream()) 
       { 
        byte[] arr = new byte[partStream.Length]; 
        partStream.Read(arr, 0, (int)partStream.Length); 
        partStream.Close(); 
       } 
      } 
     } 

     Package _package; 
     private void Button_Click(object sender, RoutedEventArgs e) 
     { 
      ReadPackage();  
     } 
} 

La méthode ReadPackage() lit tout le contenu du flux des objets PackagePart dans un tableau local. Dans l'exemple, j'ai utilisé un document XPS de 1000 pages comme source de paquet afin de voir facilement le changement de consommation de mémoire de l'application. Sur ma machine, la consommation de mémoire de l'application autonome commence à 18 Mo puis s'élève à 100 Mo après l'appel de la méthode. Appeler la méthode à nouveau peut augmenter la consommation de mémoire à nouveau, mais il peut revenir à 100 Mo. Cependant, il ne retombe plus à 18 Mo.

Quelqu'un at-il déjà rencontré ce problème lors de l'utilisation de PackagePart? Ou est-ce que je l'utilise mal? Je pense que l'implémentation interne de PackagePart met en cache les données qui ont été lues.

Merci!

Answer 1

Vous ne spécifiez pas comment vous mesurez la "consommation de mémoire" de votre application, mais vous utilisez peut-être le gestionnaire de tâches? Pour avoir une meilleure vue de ce qui se passe, je vous suggère d'examiner quelques compteurs de performance pour votre application. Les compteurs de performances de la mémoire .NET et du processus général sont disponibles.

Si vous voulez vraiment comprendre les détails de la façon dont votre application utilise la mémoire, vous pouvez utiliser le Microsoft CLR profiler.

Ce que vous voyez peut être le résultat de l'expansion du segment .NET pour prendre en charge un très gros fichier. Les gros objets sont placés sur le gros tas d'objets (LOH) et même si la mémoire .NET est récupérée, la mémoire libre n'est jamais retournée au système d'exploitation. De plus, les objets sur le LOH ne sont jamais déplacés pendant le garbage collection et ceci peut fragmenter le LOH épuisant l'espace d'adressage disponible même s'il y a beaucoup de mémoire libre.

Quelqu'un at-il déjà rencontré cette erreur lors de l'utilisation de PackagePart? Ou est-ce que je l'utilise mal?

Si vous souhaitez contrôler les ressources utilisées par le package, vous ne l'utilisez pas au mieux. Les paquets sont à usage unique et en général, vous devriez l'utiliser comme ceci:

using (var package = Package.Open(@"c:\test\1000pages.xps", FileMode.Open, FileAccess.ReadWrite, FileShare.None)) { 
    // ... process the package 
} 

A la fin des ressources des états using consommés par le paquet sont soit déjà sorti ou peuvent être garbage collection.

Si vous souhaitez vraiment conserver le membre _package de votre formulaire, vous devez à un moment donné appeler le Close() (ou IDisposable.Dispose()) pour libérer les ressources. Il n'est pas recommandé d'appeler le GC.Collect() et vous ne pourrez pas nécessairement recycler les ressources utilisées par le package. Toute mémoire gérée (par exemple, les tampons de package) accessible à partir de _package ne sera pas collectée sans tenir compte de la fréquence à laquelle vous essayez de forcer un nettoyage de place.