Speicherverbrauch .NET Anwendung



  • NullBockException schrieb:

    ABER wenn ein object freigeben weird "Aufruf Finalizer" dann geh ich mal davon aus, dass alles ressource des Objeckt freigegeben wurdn!?!? Oder kann ich auf das nich gehn?

    Ohne jetzt wirklich Ahnung von Wpf zu haben:
    Da würde ich mich jetzt nicht drauf verlassen.
    Zum Beispiel könnten Buttons eine Default-Bitmap als Hintergrund haben und diese Bitmap wird nur einmal geladen.
    Wenn der letzte Button verschwindet, könnte die Bitmap ja vorsichtshalber auch weiter im Speicher bleiben, falls wieder ein Button dargestellt wird.
    Ist aber wie gesagt nur ein Beispiel, was vielleicht sein könnte.



  • @IBV: Wenn ich wüsste, weshalb die Anwendung so viel speicher braucht, würde ich net fragen.... was genau die .NET laufzeut bzw, das WPF framework an speicher resviert etc. kann ich ja nich wirklich überwachen!

    Die Awendung ans sich istg rel. "groß" ! Man kann sich vorstellen, dass ich unterschiedliche "Views" Control habe, welche teilweile aus sehr vielen element und etc. bestehen! Diese "Views" überwache ich beim löschen .. ich instanziiere diese on demand "lazy loading" und lösche sie auch wieder bei nich gebraucht, dabei cache ich 10 views im speicher.. aber bei der freigabe eines Views, kann ich eben nich genau beurteilen was da passiert, außer der aufruf vom Finalizer..

    habe eben wenig einflus auf das managed code zeugs:)

    schönen abend euch



  • Naja, deine Frage war, wie man die lowMemory Message abschaltet.
    Wenn du wissen willst, was genau so viel Speicher braucht, dann solltest du einen Profiler benutzen. Der sagt dir das ganz genau.

    L. G.,
    IBV



  • @NullBockException
    Was bitte verstehst du unter "löschen"?
    Wie willst du in .NET 'was löschen?

    WPF ruft weder IDisposable.Dispose noch den Finalizer auf. WPF verlässt sich einfach hübsch auf den GC, der "das Objekt schon irgendwann wegräumen wird".
    Salopp gesagt.
    Für einige von WPF intern verwaltete Sachen wird das anders aussehen, also diverse Bitmap-Caches und was nicht noch alles.

    ich instanziiere diese on demand

    Wieso? Musst du das?
    Bzw. hast du schonmal probiert was passiert wenn du nix "dynamisch instanzierst", sondern einfach die normalen von WPF vorgesehenen Wege gehst?



  • Was bitte verstehst du unter "löschen"?

    Unter löschen meine ich in meinen fall, das Objekt ausm Speicher nehmen freigeben.. !

    Ich verlasse mich auch nich auf irgendwleche IDisposable Implementationen! Nach meiner Erkenntnis, ist ein Objekt "richtig" gelöscht bzw. im Speicher freigeben , wenn der GC Collected hat, und bei dem entsprechenden Objeckt dern Finalizer aufruft!

    Wenn eine WPF Control Bitmap chached, und ich diese WPF Control "lösche" , gehe ich davon aus, dass durch aufruf des Finalizer alles Ressource bzgl. der Object vom Speicher genommen werden.

    Die dynamisch Instanziierung, ist ja nichts ungewöhnliches

    Ich instanziiere ein Control, hänge es an eine ContentControl ,
    hänge es wieder ab, und setze es auf "null" danach GC.Collect Call
    danach wird der Finalizer aufgerufen..

    Ganz normales zeugs eben..



  • Also manuell GC.Collect aufrufen ist Pfusch.
    Und normalerweise unnötig.
    Gibt ein paar Spezielfälle wo man es braucht (weil WPF halt stellenweise etwas doof ist), aber normal eben nicht.

    Ansonsten...
    Ich bin jetzt kein WPF Experte, aber ich meine gelesen zu haben dass WPF sowieso eigene Caches für alle möglichen Resourcen hat. D.h. wenn du ne Bitmap in einen Button reintust, und dann den Button "löscht", dann ist deswegen noch lange nicht die Bitmap "gelöscht". Also zumindest nicht die eigentlichen Bitmap Daten.



  • Also manuell GC.Collect aufrufen ist Pfusch.

    klar is das pfusch, aber zu debug- überwachsungz/test wecken nutz ich das,

    um eben typische WPF memory leak ursachen zu finden...

    im gewöhnlichen umfeld lass ich den GV selbst seine sache machen!

    Die eigentliche bzw. wichtige frage ist: wie wpf speicher managed, und cached (bswp. bitmap files) , welche konstrukte speocher fressen!

    und das wichtigste :

    ob ich davon ausgehen kann, dass ein objeckt auch korrekt vom speicher freigeben ist, wenn der Finalizer aufgerufen wurde...

    🙂



  • Du hast nicht verstanden, dein ClientObjekte (.NET Objekte) benutzen HintergrundResourcen die ausserhalb von GC Heap liegen, und nie bereinigt werden können, weil du das Dispose-Pattern nicht anwendest! Wie kannst du von ein Objekt das schon zerstört ist, Dispose aufrufen?



  • @Zeus
    Wo gibt's bei WPF was zu disposen? Das ist ja genau eine der Schwächen (oder Stärken, je nachdem wie man es sieht), dass WPF "Dispose-frei" ist.

    Und weil du das Dispose-Pattern ansprichst: das ist mMn. der grösste Dreck den MS in letzter Zeit (softwaredesignmässig) angerichtet hat.
    Ich hab' noch nirgends Klassen gebraucht die gleichzeitig unmanaged Resourcen und "disposable" Resourcen benötigen.
    (Damit kein Misverständnis aufkommt: IDisposable ist genial. Nur void Dispose(bool disposing) ist Schwachsinn.)



  • Hmpf WinForms und WPF verwechselt 😞



  • hustbaer schrieb:

    Ich hab' noch nirgends Klassen gebraucht die gleichzeitig unmanaged Resourcen und "disposable" Resourcen benötigen.

    Das IDisposable ist ja auch für dich im nächsten Moment wenn du z.B. die Wrapper-Klasse bzw. die Klasse die auf die unmanaged Resourcen zugreift notwendig. - Schließlich gibst du die unmanaged Sachen dann mit Dispose() frei.



  • @inflames2k
    Ich verstehe deinen ersten Satz nicht.
    Was willst du mir damit sagen?
    Ja, IDisposable implementiert man dauernd irgendwo. Ich hab auch nie was anderes behauptet.

    Nur das Dispose-Pattern macht keinen Sinn.
    Falls du anderer Meinung bist, dann schreib mir bitte so dass man es auch verstehen kann warum. Also z.B. in was für einem (konkreten) Fall man es brauchen würde.


Anmelden zum Antworten