Announcement

Collapse
No announcement yet.

Auslagerungsdatei wächst und wächst

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Auslagerungsdatei wächst und wächst

    Hi,

    habe ein Problem mit einer Anwendung die grade mit VC++ Managed Extensions entwickle, das ich mir einfach nicht erlären kann. Innerhalb dieser Anwendung zeige ich ein Video aus Einzelbildern (system drawing image aus system drawing bitmap per direktem pixel in den speicher schreiben). In der Prozessübersicht ist zu beobachten wie der Speicherbedarf des Prozesses bis zu einem gewissen Punkt (meistens circa 200 MB, was knapp 200 angezeigten Bildern entspricht) anwächst und dann wieder auf ursprüngliche 50 MB zurückgeht, wieder etwas anwächst usw.

    Die Garbage Collection scheint also einwandfrei zu funktieren. (??) Jedenfalls wird die Windows Auslagerungsdatei konstant größer. Und zwar "zufällig" ziemlich genau um die Größe die die angezeigten Bilder haben. Ist die Auslagerungsdatei dann erst mal um 500 - 1000 MB angewachsen, wird das System immer langsamer bis zum fast Stillstand.


    Kennt jemand dieses Verhalten, oder weiss was man dagegen tun könnte ??


    Vielen Dank schonmal + Gruß

    Hellmut

  • #2
    Die Frage ist ob du die Infos der Prozessübersicht richtig interpretierst und nicht einfach nur der "reale" Ram-Bedarfs des Prozesses durch auslagerung sich verringert. Bei Bildbearbeitung gibt es auch unter .NET genügend Fallen speicherlöcher zu produzieren da für GDI-Ressourcen keine Garbage-Kollektion funktioniert

    Comment


    • #3
      Danke für den Tip !

      Habs hinbekommen, die Objekte vom Typ drawing image wurden offensichtlich wirklich nicht aufgeräumt. Jetzt arbeite ich immer auf dem selben Bitmap.

      Wieso funktioniert für GDI Objekte keine GC ? Hat das einen Grund und wie geht geht man da am besten damit um?

      Comment


      • #4
        Originally posted by hellmut View Post
        Wieso funktioniert für GDI Objekte keine GC ? Hat das einen Grund und wie geht geht man da am besten damit um?
        Die GDI ist keine Managed Subsystem von Windows. Und hätte man jetzt in jedem P/Invoke in das GDI-Subsystem einen "Ressourcen-GC" eingebaut wäre man performancetechnisch noch schlechter als zu Java 1.0-Zeiten gewesen.

        Umgehen tut man das am besten indem man jeden Code mit Non-Managed-Ressourcen 2 und 3 * auf Fehler untersucht (Unit-Tests lassen grüßen).

        Comment

        Working...
        X