spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Moin.

Bei einer Untersuchung meiner Programme auf Speicherlecks durch Disposable-Ressourcen (die nicht immer alle von allein freigegeben werden durch Garbage-Collection) habe ich festgestellt, dass nach Ausführung irgendwelchen Codes und durch anschließende Freigabe der dort allozierten Daten nicht wieder der Original-Zustand an Speicher-Auslastung eintritt, der vor der Ausführung gegeben war. Wird Code etwa während der Ausführung von Platte nachgeladen und bleibt dann im Speicher? Wenn ja, kann man in etwa abschätzen, wie groß der Faktor von "Exe auf Platte" und "vollständig geladenem Code" ist? Denn selbst bei kleinen Teilen des Codes, wie ich festgestellt habe, wird ziemlich viel Speicher benötigt. Ich meine... die Exe is 200k, der Speicher ändert sich aber schnell mal um einige MB, nur durch Ausführung von Code.
Oder liegt das rein an der Verwendung statischer Variablen/Konstruktoren, dass der Speicher so wächst. Denn das kann ich mir auch nicht so richtig vorstellen, da ich kaum statische Werte verwende und die meist auch nur winzig (ja, ich weiß, static is evil, aber diese werden nur gelesen und erfüllen durchaus ihren Zweck).

Edit:
Ich habe jetzt mal direkt den Speicher vom Garbage-Collector erfragt.
Vor der Ausführung der Code-Blöcke waren ~450k alloziert. Danach ~520k. Erneute Ausführung bewirkt nichts (ja, doch, so +-15 Bytes). Wo kommen die 70k her? Statische Variablen kann nicht sein, Disposable-Ressourcen werden keine verwendet.

Danke im Voraus

Genau das habe ich natürlich in meinem Test getan - ich habe GC.Collect() aufgerufen und bei GC.GetTotalMemory() angegeben, dass er mir die Angabe des Speichers nach vollständiger Collection zurückgeben soll.

Wie ich schon sagte, es ist mir aufgefallen, als ich Bugs/Lecks bezüglich IDisposable Ressourcen ausgemerzt habe, die Programm-Codes aus meinem Test enthielten aber keinerlei solcher Ressourcen. Alle Angaben beziehen sich auf Managed Heap.

Die Speicher-Änderung der nicht-Managed-Sachen, sprich die Angaben im Task-Manager sind aber ebenfalls von Interesse (der von mir erwähnte Faktor), da diese sich deutlich ändern, auch wenn der Managed Heap sich nicht ändert.

Das war ja genau der Grund, warum ich nach Lecks gesucht hatte. Die sind nun weg.

Spannend finde ich das Verhalten aber dennoch.

Joar, aber könnte ja sein, dass es da gewisse Profiling Erfahrungen gibt.