La lectura desde la transmisión PackagePart no libera la memoria

Question

En nuestra aplicación, estamos leyendo un archivo XPS utilizando la clase System.IO.Packaging.Package. Cuando leemos de un flujo de un paquete compartido, podemos ver en el Administrador de tareas que aumenta el consumo de memoria de la aplicación. Sin embargo, cuando se realiza la lectura, el consumo de memoria no vuelve a ser lo que era antes de leer desde la secuencia.

Para ilustrar el problema, escribí un ejemplo de código simple que puede usar en una aplicación wpf independiente.

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();  
     } 
} 

El método ReadPackage() leerá todos los contenidos de transmisión en los objetos PackagePart en una matriz local. En la muestra, utilicé un documento XPS de 1000 páginas como fuente del paquete para ver fácilmente el cambio en el consumo de memoria de la aplicación. En mi máquina, el consumo de memoria de la aplicación independiente comienza en 18 MB y luego aumenta a 100 MB después de llamar al método. Llamar nuevamente al método puede aumentar el consumo de memoria, pero puede volver a 100MB. Sin embargo, ya no recae en 18MB.

¿Alguien ha experimentado esto al usar PackagePart? ¿O lo estoy usando mal? Creo que la implementación interna de PackagePart está almacenando en caché los datos que se leyeron.

¡Gracias!

Answer 1

No especifica cómo se mide el "consumo de memoria" de su aplicación, pero ¿quizás esté utilizando el administrador de tareas? Para obtener una mejor visión de lo que está sucediendo, le sugiero que examine algunos contadores de rendimiento para su aplicación. Están disponibles los contadores de rendimiento de la memoria de proceso general y montón de .NET.

Si realmente quiere comprender los detalles de cómo su aplicación utiliza la memoria, puede usar el Microsoft CLR profiler.

Lo que ve puede ser el resultado del despliegue del montón .NET para acomodar un archivo muy grande. Los objetos grandes se colocan en el montón de objetos grandes (LOH) e incluso si la memoria .NET es basura, la memoria gratuita nunca se devuelve al sistema operativo. Además, los objetos en el LOH nunca se mueven durante la recolección de basura y esto puede fragmentar el LOH agotando el espacio de direcciones disponible a pesar de que hay mucha memoria libre.

¿Alguien ha experimentado esto al usar PackagePart? ¿O lo estoy usando mal?

Si desea controlar los recursos utilizados por el paquete, no lo está utilizando de la mejor manera. Los paquetes son desechables y, en general, se debe utilizar la siguiente manera:

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

Al final de los recursos de los estados using consumidos por el paquete o bien están ya en libertad o pueden ser basura recogida.

Si realmente desea conservar el miembro _package de su formulario, en algún momento debe llamar al Close() (o) para liberar los recursos. No se recomienda llamar al GC.Collect() y no será necesariamente capaz de reciclar los recursos utilizados por el paquete. Cualquier memoria administrada (por ejemplo, almacenamientos intermedios de paquetes) a la que se pueda acceder desde _package no será basura recolectada, sin importar la frecuencia con la que trate de forzar una recolección de basura.