Button frisst Speicher?

[EmWieMichael]

Moin!

Bei der Entwicklung eines Fenstermanagers ist mir aufgefallen, dass nach Create, Show und Release eines Formulars laut "GetMemoryManagerState" (TotalAllocatedMediumBlockSize) mehr Speicher vom Programm genutzt wird, als vor dem Aufruf des Formulars; und zwar 3.628 Bytes. Dabei ist es unerheblich, ob das Fenster nur einmal oder auch ein Dutzend mal gleichzeitig angezeigt wird.
Als Verursacher konnte ich TAdvGlowButton von TMS identifizieren. Einen kurzen Blick in den Quellcode des Buttons habe ich schon gewagt, muss aber zugeben, dass meine Kenntnisse in Sachen Komponentenentwicklung nicht ausreichen, um hier zielführend weiterzukommen :cry:.

Ist das Verhalten der Buttonkomponente 'normal'? Oder sollte man besser auf den Einsatz verzichten?

Michael

[Schokohase]

Du machst dir einen Kopf weil da einmalig ca. 3KB Speicher benötigt wird?

Für mich hört sich das nach einer Bitmap-Resource (evtl. der Glow-Effect) an, die von nun an im Speicher gehalten wird, und diese wird für alle (auch zukünftigen) Button-Instanzen verwendet (um Speicher zu sparen und die Performance zu steigern)

[ConnorMcLeod]

Finde ich in Ordnung.

@Michael: das kann man im Prinzip leicht feststellen indem Du den Button gegen einen Standardbutton austauschst, oder?

[EmWieMichael]

Vermutlich mache ich mir tatsächlich unnötig einen Kopf, das mag schon sein. Aber ich würde ganz gerne verstehen, warum der Speicher nicht sauber aufgeräumt wird. Eigentlich (!) bin ich bisher davon ausgegangen, dass mit einem TForm.Release alles aus dem Speicher entfernt wird, was durch die Form erzeugt wurde (Und jetzt wackelt mein Weltbild :shock:).
Die Frage nach dem Standardbutton: Ja, mit dem Standardbutton - oder auch mit anderen TMS-Buttons - wird der Speicher wieder auf Ausgangsgröße zurückgesetzt.

[CCRDude]

Zitat:

Zitat von EmWieMichael (Beitrag 1424722)

Aber ich würde ganz gerne verstehen, warum der Speicher nicht sauber aufgeräumt wird

Solange Du den Code nicht gelesen und das Leak gefunden hast, ist kein Urteil in Sachen "sauber" mMn unangebracht.

Wie oben schon geschrieben wurde: unter Umständen cached die Button-Klasse (nicht das Objekt) etwas, und wenn dieser Cache dann neu geöffnete weitere Fenster sich ein paar Millisekunden schneller öffnen lässt, ist das unter Umständen mehr wert als 3 KB Arbeitsspeicher.

Ich verwende in Debug-Versionen immer heaptrc (FreePascal), das loggt bei mir Beenden alle Memory Leaks. Etwas ähnliches gibt es doch auch in Delphi. Im Zweifel würde Dir das wohl auch ausspucken, in welcher Datei und welcher Zeile dieser Cache aufgebaut wird (wenn er nicht bei Programmende ordentlich zerstört wird).

[DP-Maintenance]

Dieses Thema wurde am "05. Feb 2019, 11:33 Uhr" von "Luckie" aus dem Forum "Algorithmen, Datenstrukturen und Klassendesign" in das Forum "GUI-Design mit VCL / FireMonkey / Common Controls" verschoben.

[Redeemer]

Bei Delphi gibt es ReportMemoryLeaksOnShutdown, das setzt man am Anfang in den Projektquelltext.

[TurboMagic]

Genau: in die dpr deines Projektes gehen und als erste Zeile nach dem begin das reinschreiben:

ShowMemoryLeaksOnShutdown := true;

Wenn's welche gibt, gibt's bei Programmende ein Fensterchen mit Daten dazu.
Wer's jedoch wirklich genau wissen will, lädt die komplette FastMM4 Version runter,
stellt die include Datei richtig ein (da legt man das Verhalten fest) und kann dann
durch fastMM4 im Uses das einbinden und sogar sehen wo das leakende Objekt erzeugt worden ist...