SelectMany nimmt sehr viel Speicher mit ReactiveExtensions

Question

Ich möchte eine Pipeline erstellen, die Bilder aufnimmt und einige abgeleitete Objekte zurückgibt.

Ich benutze eine Sequenz von Bitmaps und für jeden von ihnen ich die Aufgabe (das ist asynchron). Es ist also so einfach wie es scheint. Ich habe jedoch herausgefunden, dass der Speicherverbrauch wirklich hoch ist. Um das Problem zu veranschaulichen, habe ich diesen Test erstellt, den Sie ausführen können.

Bitte schauen Sie sich den Speicher an, da er bis zu 400 MB RAM benötigt.

Was kann ich tun, um so viel Speicher zu vermeiden? Was passiert hier?

[Fact] 
public async Task BitmapPipelineTest() 
{ 
    var bitmaps = Enumerable.Range(0, 100).Select(_ => new WriteableBitmap(800, 600, 96, 96, PixelFormats.Bgr24, new BitmapPalette(new List<Color>() { new Color() }))); 
    var bitmapsObs = bitmaps.ToObservable(); 

    var processed = bitmapsObs.SelectMany(bitmap => DoSomethingAsync(bitmap)); 
    processed.Subscribe(); 

    await Task.Delay(20000); 
} 

private async Task<object> DoSomethingAsync(BitmapSource bitmap) 
{ 
    await Task.Delay(1000); 
    return new object(); 
} 

Answer 1

So glaube ich nicht, das Problem zu SelectMany oder auch reaktiven Erweiterungen notwendigerweise zurückzuführen ist. Es sieht so aus, als ob WriteableBitmap nicht verwalteten Speicher verwendet: source code. Ich glaube, das Problem ist, dass Sie in sehr schneller Folge eine Menge relativ kleiner verwalteter Objekte erstellen, die viel mehr nicht verwalteten Speicher belegen. Vom MSDN:

Wenn ein kleines verwaltete Objekt eine große Menge an nicht verwalteten Speicher zuweist, nimmt die Laufzeit berücksichtigt nur den verwalteten Speicher und unterschätzt damit die Dringlichkeit der Planung der Garbage Collection.

Aber wir können die Garbage Collector Hinweise geben, indem sie die GC.AddMemoryPressure und GC.RemoveMemoryPressure Funktionen. Dies wird dem GC helfen, seine Planung zu verbessern. Bevor wir das tun können, müssen wir eine Vorstellung davon haben, wie viel nicht gemanagter Speicher zugewiesen wird. Ich glaube, dass der nicht verwaltete Speicher verwendet wird, um das Pixelarray zu speichern, so dass ich denke, eine gute Schätzung ist die Pixelbreite mal die Pixelhöhe mal die Anzahl der Bits in jedem Kanal multipliziert mit der Anzahl der Kanäle. Von der MSDN sieht es aus, als ob es 32 Bits (4 Bytes) pro Kanal und 4 Kanäle gibt.

lief ich einige Tests Code ähnlich dem folgenden verwenden und haben wirklich gute Ergebnisse:

var processed = 
    Enumerable 
    .Range(0, 100) 
    .Select(_ => new WriteableBitmap(
     800, 
     600, 
     96, 
     96, 
     PixelFormats.Bgr24, 
     new BitmapPalette(new List<Color>() { new Color() }))) 
    .Select(x => new { Bitmap = x, ByteSize = x.PixelWidth * x.PixelHeight * 4 * 4) 
    .ToObservable() 
    .Do(x => GC.AddMemoryPressure(x.ByteSize)) 
    .SelectMany(x => DoSomethingAsync(x.Bitmap)); 

processed 
.Subscribe(x => GC.RemoveMemoryPressure(x.ByteSize)); 

Allerdings, wenn Ihre Quelle schneller veröffentlicht Bitmaps, als Sie sie Sie werden dann behandeln können immer noch Probleme haben,. Der Gegendruck bewirkt, dass der Speicher schneller zugewiesen wird als freigegeben werden kann.

Ehrlich gesagt, haben Sie wirklich Bitmaps zu Ihnen geschoben? Ich habe keine Ahnung, wie Ihr aktuelles Programm aussieht, aber in Ihrem Beispielcode ist das ein Pull-basiertes System. Wenn es sich um ein Pull-basiertes System handelt, haben Sie in Betracht gezogen PLINQ? PLINQ ist großartig für diese Art von Ding; es gibt Ihnen wirklich gute Kontrolle über Nebenläufigkeit und Sie müssen sich nicht über Gegendruck sorgen.

Answer 2

Es scheint mir, dass Sie in eine einfache Speicherbelegung Problem auftreten.

Wenn es 4 Bytes pro Kanal und 4 Kanäle pro Pixel gibt, dann sind Ihre 1000 Bilder bei 800 x 600 jeweils 1000 x 800 x 600 x 4 x 4 = 733MB (ungefähr).

Was mir jedoch in Ihrem Code auffällt, der Ihnen Kummer bereiten könnte, ist, dass Sie mit einem Aufzählungszeichen beginnen und es dann in ein Observable verwandeln, das mithilfe von Tasks erstellt wird, die Sie am Ende ausführen asynchron mit einem Feuer und vergessen .Subscribe() und Sie täuschen die Rückkehr mit einem await Task.Delay(20000);. Es ist alles anfällig für Fehler. Sie sollten es vermeiden, Ihre "Monaden" zu mischen.

Hier ist, wie ich es schreiben würde:

public async Task BitmapPipelineTest() 
{ 
    await 
     Observable 
      .Range(0, 100) 
      .Select(_ => new WriteableBitmap(
       800, 600, 96, 96, 
       PixelFormats.Bgr24, 
       new BitmapPalette(new List<Color>() { new Color() }))) 
      .SelectMany(x => 
       Observable 
        .Start(() => 
        { 
         Thread.Sleep(10); 
         return new object(); 
        })); 
}