Allozierter Speicher steigt und steigt

[Anthony S]

Nach mehrmaligem dynamischen Erzeugen und Freigeben von MDI-Fenstern, in denen zugegebenerweise komplexe Inhalte vorhanden sind, zeigt der WindowsNT-Taskmanager für die Applikation immer mehr verwendeten Speicher an.

Ich habe überprüft, ob Objekte, die keinen owner haben, vergessen wurden nach einem Create auch wieder mit Free freigegeben zu werden. In der Tat gab's da auch ein paar. Nur: Es hatte auf den Verbrauch keinen ernsthafte Auswirkung. Es hat sich weder gebessert noch verschlechtert. Weiterhin verbraucht ein MDI-Formular nach dem Schließen mindestens ca 4 KB .... in komplexen Fällen sind es sogar bis zu 40 ...

Ich bin nun auf der Suche nach Ideen und Möglichkeiten, wie es zu Speicherschwund kommen kann und inwieweit die NT-Taskmanager-Anzeige überhaupt diese Sorgen gerechtfertigt.

Kann es sein, dass Delphi erst verzögert freigegebenen Speicher wieder über eine Garbage Collection dem Taskmanager bekanntgibt??

Gruß Anthony

[Andreas Kosch]

Hallo,

das kommt darauf an, was in diesen Fenstern gemacht wird. Delphi verwendet einen eigenen Speichermanger (den man allerdings über die von Borland vorgesehene Schnittstelle durch einen eigenen ersetzen kann), der jeden angeforderten Block zurück in den Pool legt, und nicht freigibt. Dies ist im Normalfall auch sehr effektiv, da bei der nächsten Anforderung ein Speicherblock aus dem Pool geholt wird. Allerdings gibt es immer dann ein Problem, wenn eine Anwendung bei jeder neuen Anforderung einen immer grösser werdenden Speicherbereich anfordert, denn in diesem Fall ist kein "passendes" Stück im Pool vorhanden, so dass Delphi das Stück vom Betriebssystem anfordert. Somit wächst der Pool ständig an, so dass dieser angeforderte Speicher tatsächlich erst zum Programmende freigegeben wird.

Zum Test würde ich daher Delphi mit den Aufruf-Parametern <b>/hm</b> starten, da Delphi dann den Speicherverbrauch in der Fensterzeile anzeigt. Alternative kann man im eigenen Programm auch regelmässig die Statusvariablen <b>AllocMemCount</b> und <b>AllocMemSize</b> auswerten bzw. mitprotokollieren. Zuguterletzt steht auch noch die Win32-API-Funktion <b>GetHeapStatus</b> zur Verfügung, um der Sache näher auf den Grund zu gehen (die Funktion liefert über THeapStatus 10 Werte zurück).

Spätestens beim Programmende (d.h. dem Ende des Prozesses) räumt Windows automatisch alle "vergessenen" Bereiche ab. Falls die Debug-Version von Windows zur Verfügung steht, kann man sich diese "Meckerliste" vom Betriebssystem über den <b>WinDbg Debugger</b> anzeigen lassen ;-)
&#10