Einzelnen Beitrag anzeigen

Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
43.202 Beiträge
 
Delphi 12 Athens
 
#17

Re: FastMM grotten langsam ?!

  Alt 18. Nov 2005, 16:59
Zu Hagen's Beitrag #13:
Bei RecyclerMM kann ich bestätigen, daß dieser mit verschiedenen Modulen (DLLs und Co.) nicht klar kommt.

Für FastMM trift dieser aber auch nur bedingt zu, denn dort muß die entsprechende Funktionalität erst aktiviert werden und selbt dann steht dieses nicht volltändig zur Verfügung, denn die Memory-Funktionen sind nicht vollständig für SharedMemory ausgelegt.
GetMem, FreeMem und ReallocMem können zwar vollständig für alle Threads/Module freigegeben werden, aber bei den Zusatzfunktionen wie z.B. für den UsageTracker sieht es anders aus, denn diese greifen nur auf den in ihrem Bereich liegenden MM zu, selbst wenn es nicht der global initialisierte MM ist, was zu netten Problemen führen kann/wird.

Mein MM ist da schon konsequenter und gibt alle nötigen Funktionen global frei.
Also jeder FastXMM schaut immer erstmal nach, ob es im Programm schon irgendwo einen weiteren FastXMM gibt und übergibt dann die kontrolle an diesen.
Ich muß allerdings zugeben, daß ich aber auch noch nicht zu 100% konsequent bin, denn es gibt "noch" ein kleines Problem, was aber extrem selten auftritt.
Also wenn z.B. in mehreren dynamisch geladenen Moduelen (DLLs...) der FastXMM enthalten ist und zusätzlich aber keiner in einem statisch geladenen Modul, oder im Hauptmodul (EXE), dann wird es zu Problemen kommen, sobald nicht das zuerst geladene Modul auch als letztes freigegeben wird. (bei den anderen ist die Reihenfolge egal)
Allerdings haben dieses Problem auch alle anderen Memory Manager, welche ich bisher gesehn hab und dazu kommt noch, daß dieses Problemchen in der nächsten Generation meinen FastXMM behoben wird.



Solche CleanUp-Funktionen (Beitrag #14) wären aber auch nicht nötig, wenn die Programmierer, so wie es auch eigentlich der Fall sein sollte, beim Beenden der verschiedenen Teile darauf achten würden, daß auch wirklich alles Nötige freigegeben wird, daher ist in Fast(X)MM derartiges erst garnicht implementiert. ^^
Es wird "nur" beim Programmende (sobald FastXMM freigegeben wird) geprüft, ob noch irgendwas allociert ist, welches ja eigentlich nicht de Fall sein dürfte, wenn alles ordnungsgemäß freigegeben wurde.



Und was nochmal den Speichermehrverbrauch bei Fast(X)MM angeht, so ist dieser beim Aufruf von GetMem/FreeMem nicht wesentlich anders, als bei BorlandMM.
Nur beim ReallocMem wird entweder nicht sofort, oder im vollständigen Maße verkleinert, ebenso wird beim Vergrößern halt etwas mehr gemacht, da hierbei für einen zukünftigen Aufruf von ReallocMem vorgesorgt wird. Und wenn man sich dazu noch den Benchmark (Anzahl der Aufrufe der einzelnen Memory-Funktionen) ansieht, dann wird deutlich, daß der größte Teil an Aufrufen nicht beim ReallocMem liegt, wodurch also viel öfters passend Allociert wird, und somit meißtens "kein" Mehrverbrauch zu erwarten ist.



Und wie Hagen schon sagte kann man nicht für alles den MM verantwortlich machen, denn man hat auf vieles selber Einfluß und kann selber an vielen Stellen verbesserungen innerhalb der eigenen Codes hervorrufen.

Und was die Fragmentierung anmgeht, so scheint BorlandMM wohl ganz schöne Probleme zu haben, welche bei anderen nicht so stark auftreten.



PS: @Hagen
In deinem letzten Beitrag (#16) sagtest du was von 'ner Art Cache ... was meinst du, wenn man etwas derartiges direkt in den MM mit einbauen könnte ... also z.B. spezielle GetMem/FreeMem, welche auf einen Cache mit vorher festgelegen Blockgrößen zugreift?



[add]
Manchmal ist man auch sowas von Blind
eine entsprechende Funktionalität für einen benutzerdefinierten Cachebereich existiert ja schon und wird fleißig für alle Speicherblöcke bis 2 KB - 4 Byte verwendet.

Im grunde genommen brauchte ich ja nur dieses erweitern und lediglich eine Procedur zum Initialisieren der einzelnen Cacheguppen erstellen.
Und könnte dann alles über die Standardfunktionen (GetMem/FreeMem) laufen lassen ... wobei ich dann dort wohl lieber noch Konstanten für den schnelleren Zugriff auf eine bestimme Cachegruppe einführen, welche dann statt der gewünschten Blockgröße (Size) angegeben wird ... wäre ja nicht gerade effektiv immer erst nachzusehen ob eine gewünschte Größe (Size) zufällig in einem der Cacheblöcke vorhanden ist

Also, wenn jemand sowas gebrauchen könnte/würde, dann bitte melden ... man muß sich ja nicht mehr Arbeit machen, also unbedingt nötig -.-''
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
my Delphi wish list : BugReports/FeatureRequests
  Mit Zitat antworten Zitat