WPF-Fenster und Ressourcenverbrauch nach dem Schließen

Hallo!

lasse ich mir im Taskmanager den Ressourcenverbrauch anzeigen wird beim Öffnen eines WPF-Fensters ca. 2-10 MB mehr Arbeitsspeicher verbraucht. Aber nach dem Schließen des Fensters mit Close() bleibt der Speicher weiter unverändert.

Nun gibt es ja den GC, der die Ressourcen dann wieder automatisch freigibt und dessen Verhalten man scheinbar nicht steuern kann.

Aber arbeitet man mit der Anwendung, werden aus 100 MB Anfangs-Speicherverbrauch schnell 300 MB. etc.

Gibt es noch nach Close ein Befehl, mit dem man wirklich Aufräumen kann. Wo kann ich den Ressourcenverbrauch genau überprüfen?

Danke

Der Taskmanager beim Thema Speicherverbrauch ist so aussagekräftig wie eine Wahrsagerin im Zelt auf der Kirmes.

Verwende einen Profiler, um den Speicher genau nachvollziehen zu können.
Du wirst schnell entdecken, dass sich .NET immer mehr Speicher reserviert, als in Verwendung ist. Die Reservierung selbst erfolgt in Stufen.

Es gibt mehrere Profiler; mittlerweile auch direkt in VS.
Ich finde aber der ANTS Profiler ist der für mich beste auf dem Markt in Sachen Nachvollziehbarkeit, Funktion und Übersicht; nur als Tipp (ich krieg für die Werbung leider kein Geld o.ä.).

Hallo Abt!

Danke für den Tipp mit dem Profiler. 👍 Da gehen allerdings die Preise bei 375 € los und enden bei 775 €. Gibt es erst einmal einen empfehlenswerten Freeware-Profiler?

Kann man sonst irgendwie die GC nach dem Schließen erzwingen? Close() müsste ja alles tatsächlich schließen. Hängende Referenzen dürfte es ja beim .NET nicht geben? Oder könnte ich diese erst einmal mit VS Bordmitteln lokalisieren?

Danke!

Wenn Du Managed Ressourcen richtig verwendest brauchst Du Dich um den GC nicht kümmern. Wenn IDisposable verwendet wird sollte das immer in ein using(). Ein Close reicht in den meisten Fällen auch, da Close() in Framework-Implementierungen _normalerweise _immer Dispose(true) aufruft.

Wenn Du an den Punkt kommst, dass GC.Collect() für Dich wichtig ist, dann machst Du definitiv was gravierend falsch.

Ab VS 2012 ist ein Profiler bereits integriert (Analyze Tab).

Wenn für Dich die Anzeige im TaskManager entscheidend ist, dann hast Du das .NET System ohnehin nicht verstanden.
Ich würde mich um den Speicher erst kümmern, wenns wirklich nicht mehr plausibel ist. Aber 300MB bei WPF ist jetzt ned grade viel, wenn man bedenkt, dass davon zwischen 5 und 20% .NET pauschal als Mehrplatz für sich einnimmt.

Hallo Abt!

Danke nochmals! 👍 Dann nutze ich erst einmal den integrierten Profiler.

Das .NET dann für ein einfaches Programm mal schnell 300 MB benötigt, wenn man WPF-Fenster einfach immer wieder öffnet und schließt kann ich trotzdem nicht ganz nachvollziehen.

Wenn die GC nur dann etwas cleared, wenn sie denkt, dass es gerade geht weil wenig "los" ist und es wahrscheinlich nicht mehr benötigt wird ist mir klar.

Aber ich dachte, der Vorteil der GC liegt darin, wenn ich ein Fenster mehrmals öffne und schließe die GC das erkennt und dann die alten Ressourcen erneut nutzt und so nicht mehr Speicher benötigt und die Aktion schneller durchführen kann.

Ich komme halt von der normalen "nicht-.NET" Entwicklung, wo die Programme um ein Vielfaches kleiner sind.

ALSO heißt das: Close() räumt tatsächlich alles weg und die GC kümmert sich sehr viel später darum. Ich werde mir dann keinen Kopf mehr machen.

Danke

Hi m.grauber,

der vom GC verwaltete Speicher hat nichts mit der Anzeige im TaskManager zu tun. Dazu gab es bereits einige Beiträge hier im Forum, wo auch beschrieben wurde, warum da kein Zusammenhang besteht, und welche Informationen dir die Anzeige im TaskManager in diesem Zusammenhang liefert (nämlich keine). Ausführliche Beschreibungen gibt es auch bei MSDN, CodeProject und StackOverflow.

Deine Frage kannst du dir also ganz leicht über die Forensuche oder Google beantworten lassen. Daher hab ich den Beitrag jetzt auch geschlossen, um weitere Nachfragen zu diesem Thema zu vermeiden.

Bitte beachte in Zukunft [Hinweis] Wie poste ich richtig?, Punkt 1.1.

Christian