Hi,

derzeit entwickel ich an einem System, welches mittlerweile einen erheblichen Umfang erreicht hat.

Es handelt sich dabei um ein Datenbankprojekt, in dem Datensätze
verwaltet werden etc.

Um Speicherlöcher zu vermeiden verwende ich FastMM4.
Bis jetzt hat sich das auch als ganz brauchbar erwiesen, da immerhin
auch manchmal andere Bibliotheken (Jedi, Indy) Speicherlöcher verursachen oder
man aus Flüchtigkeit selbst vergisst Speicher freizugeben.
Wie dem auch sei.

Ich habe nun ein seltsames Problem, was die Speicherauslastung unter Windows betrifft.
Starte ich das Programm, zeigt der Task-Manager mir ~11 MB Speicherauslastung an.
Verkleiner ich das Programm in die TNA, werden mir nur noch ~2 MB Speicherauslastung
angezeigt.
Hole ich das Programm wieder auf den Bildschirm, werden ~3 MB Speicherauslastung angezeigt.
Die letzten beiden Schritte sind bei jedem Versuch identisch.
D.h. verkleinert ~2 MB, vergrößert ~3 MB.

Öffne ich einen Datensatz, werden ~8 MB Speicherauslastung angezeigt, ausgehend von ~3 MB.
D.h. es werden ~5 MB zusätzlich verwendet.
Verkleiner ich das Programm wieder, obwohl der Datensatz offen ist, sind es nur noch ~3,5 MB. Vergrößer ich das Programm sind es ~5 MB.
Auch diese beiden letzten Schritte sind reproduzierbar d.h. verkleinert ~3,5 MB und vergrößert ~5 MB.

Verkleinere ich das Projekt garnicht und starte bei ~11 MB und öffne Datensätze, steigt die Speicherauslastung drastisch. (~11 MB + ~5 * x)

Was mir aufgefallen ist, ist die Tatsache, dass der Speicher, der durch einen Datensatz angefordert wird, beim Schließen des Datensatzes erst dann völlig aus dem Speicher verschwunden ist, wenn ich das Programm einmal in die TNA minimiert und von dort wieder maximiert habe.


Ich vermute, dass beim Verkleinern das System prüft, ob Speicherleichen oder nicht dem System zurückgeführter Speicher noch vorhanden ist und der Speichermanager räumt auf.
Vermutlich kümmert sich der Windowsspeichermanager auch bei Zeiten darum, selbst wenn die Applikation läuft.
Darauf zu warten ist aber ungesund, wenn das zu lange dauert. Zumal dies in bisherigen Testläufen nicht der fall war.

Kann man diesen Prozess eventuell beschleunigen?

Danke

Ich hab jetzt mit JCL Debug und FastMM4 im FullDebugMode das ganze Programm nochmal gecheckt...
und habe 1 übrig gebliebenes Speicherloch entdeckt.

Hat keiner 'ne Idee, oder ähnliches bis jetzt gehabt?

Lass dir im Taskmanager auch mal den virtuellen Speicher anzeigen. Habe das Phänomen auch öfters - das scheint mit dem Speichermanagment von Windows zusammenzuhängen, das beim Minimieren das eine oder andere auslagert und beim Wiederherstellen nicht direkt zurückholt.
Der virtuelle Speicher sollte einigermaßen konstant bleiben.

Danke für den Tip.
Der Virtuelle Speicher konstant bei ~7 MB.

Evtl. sind das genau die 7 MB, welche am Anfang direkt und später im virtuellen Speicher liegen?
Würde die ursprünglichen 11 MB zwar nicht ganz, aber teilweise erklären.
Wenn der Taskmanager die gesamte Speicherauslastung berücksichtigt.
Na mal sehen.
Ich werd das Programm nochmal gründlich mit Programmen wie MemProof prüfen und Programme wie ProcessExplorerNT von SysInternals.
Eventuell finde ich dann genauere Hinweise.

Danke

Ich kenn das auch. Das ist wirklich der Speichermanager von Windows. Versuche, einen eigenen SM zu implementieren. Wenn Du z.B. fast ausschließlich Objekte des Typs 'TMyObject' verwendest, dann kannst Du, anstatt die Objekte über 'Free' freizugeben, diese in eine TList packen. Anstatt ein Objekt neu zu alloziieren, schaust Du zunächst in der TList nach, ob da nicht ein altes, nicht mehr benötigtes, Objekt rumschwirrt.

In meiner Anwendung (DB-Engine) werden so beim Programmstart einmalig 20.000 Seiten alloziiert und in die Freispeicherliste gepackt. Damit kommt die Anwendung klar, und ich bin diese obskuren -nicht vorhandenen- Speicherlöcher los. Der Speicher schnellt sofort auf 160MB hoch und bleibt da.

Übrigens: Der SQL-Server von Microsoft verwendet den SM aus dem eigenen Hause auch nicht, sondern macht es, wie oben beschrieben.

Danke für die Info.
Für 'nen Speichermanager hab ich Momentan keine Zeit,
aber mal sehen.

Thx.

Hey, sowas ähnliches passiert sogar unter Outlook Express, er meldet sich zunächst mit 11.000K, wenn ich verkleinere nur 675 K, wenn ich wieder vergössere 6.000 K, das hängt also mit der Speicherverwaltung in Win zusammen. Er verwaltet es ja eh automatisch. Ich würde höchstens mal gucken, ob Deine Auslagerungsdatei über den Tag, wo das Programm läuft, immer weiter wächst...

Diese Phänomen konnte ich bei diversen Programmen beobachten.
Ich werde diesbezüglich also mein Programm genau im Auge behalten.

Darum sollteste dich aber nicht kümmern müssen. Windows lässt freigegeben "offiziell" als besetzt liegen, damit ein Programm, wenn es wieder so viel braucht, schneller seinen benötigten RAM bekommt. Daher kommt der Effekt, wie es schon oft gesagt wurde. Sobald Windows allerdings merkt, dass der RAM nicht reicht, müsste er den "offiziell" freine, aber "inoffiziell" freien Speicher, wieder komplett freigeben, also diesmal richtig. Allerdings muss man dazu sagen, dass Windows nicht die komplette Schuld besitzt. So weit ich weiß gehen die Delphi-Speichermanager so ähnlich ran um den Effekt von "Vorreservierungen" zu verbessern .