Odczytywanie ze strumienia PackagePart nie zwalnia pamięci

Question

W naszej aplikacji odczytujemy plik XPS przy użyciu klasy System.IO.Packaging.Package. Kiedy czytamy ze strumienia PackagePart, widzimy w Menedżerze zadań, że wzrasta zużycie pamięci aplikacji. Jednak po zakończeniu odczytu zużycie pamięci nie powróci do wartości sprzed odczytu ze strumienia.

Aby zilustrować problem, napisałem prosty przykład kodu, którego można użyć w samodzielnej aplikacji wpf.

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

Metoda ReadPackage() odczyta zawartość strumienia obiektów PackagePart do lokalnej tablicy. W próbce użyłem dokumentu XPS o wielkości 1000 stron jako źródła pakietu, aby łatwo zobaczyć zmianę zużycia pamięci aplikacji. Na moim komputerze zużycie pamięci samodzielnej aplikacji zaczyna się od 18 MB, a następnie wzrasta do 100 MB po wywołaniu metody. Ponowne wywołanie metody może ponownie zwiększyć zużycie pamięci, ale może wrócić do 100 MB. Jednak już nie wraca do 18 MB.

Czy ktoś doświadczył tego podczas korzystania z PackagePart? Czy używam go źle? Myślę, że wewnętrzna implementacja PackagePart buforuje odczytane dane.

Dziękujemy!

Answer 1

Nie określasz sposobu mierzenia "zużycia pamięci" w swojej aplikacji, ale może używasz menedżera zadań? Aby uzyskać lepszy obraz tego, co się dzieje, sugerujemy zbadanie niektórych liczników wydajności dla twojej aplikacji. Dostępne są zarówno sterty .NET, jak i ogólne liczniki wydajności pamięci procesowej.

Jeśli naprawdę chcesz zrozumieć, w jaki sposób twoja aplikacja korzysta z pamięci, możesz użyć Microsoft CLR profiler.

To, co widzisz, może być wynikiem powiększania się stosu .NET, aby pomieścić bardzo duży plik. Duże obiekty są umieszczane na stertach dużych obiektów (LOH), a nawet jeśli pamięć .NET jest zbędna, wolna pamięć nigdy nie jest zwracana do systemu operacyjnego. Ponadto obiekty na LOH nigdy nie są przenoszone podczas usuwania śmieci, co może powodować fragmentację LOH, wyczerpując dostępną przestrzeń adresową, mimo że jest dużo wolnej pamięci.

Czy ktoś tego doświadczył podczas korzystania z PackagePart? Czy używam go źle?

Jeśli chcesz kontrolować zasoby używane przez pakiet nie używasz go w jak najlepszy sposób. Paczki są jednorazowego użytku i w ogóle powinna go używać tak:

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

Pod koniec using rachunku zasobów zużywanych przez pakiet albo są już zwolnione lub mogą być zbierane śmieci.

Jeśli naprawdę chcesz zachować element członkowski formularza _package, powinieneś w pewnym momencie zadzwonić pod numer Close() (lub IDisposable.Dispose()), aby zwolnić zasoby. Dzwonienie pod numer GC.Collect() nie jest zalecane i nie będzie w stanie odtworzyć zasobów używanych przez pakiet. Jakakolwiek pamięć zarządzana (np. Bufory pakietów), które można uzyskać od _package, nie będzie zbierana podczas czyszczenia pamięci, bez względu na to, jak często będziesz wymuszał zbieranie śmieci.