FastMM grotten langsam ?!

[himitsu]

So, ich bins nochmal ^^

Also, da ich mir ja mal ein/zwei MemoryManager angesehn und mir sozusagen auch noch 'nen eigenen Angeschaft habe, kann ich dir schonmal eines sagen ...

und zwar ist der FastMM was das Reservieren und Freigeben von Speicher angeht nicht schneller als der normale MemoryManager von Delphi.
Und das Ändern der Speichergröße (Realloc) ist nur in einem begrenzten Bereich etwas schneller.
Selbst Meiner ist da keine Ausnahme.
Und zwar ist es so, das bei FastMM und FastXMM in Wirklichkeit nicht immer die Speicherzuweisung geändert wird - der normale MM führt ein Realloc immer durch.
Es ist so, daß solange sich die Größenänderung innerhalb eines gewissen Bereichs (von der bereits reservierten Speichermenge abhängig) bewegt der Speicher nicht neu zugewiesen wird ... also wenn keine Änderung geschieht, dann wird natürlich Zeit eingespart

Zusätztlich hat mein MM eine etwas Einteilung der "kleineren" Speicherblöcke (bis 2 KB), was insgesammt einer etwas schneller Speicherbehandling resultieren sollte.

Und wie gesagt, der FastMM und mein FastXMM sind hauptsächlich beim Realloc etwas besser.
Es gibt zwar abundzu mal 'ne Geschwindigkeitssteigerung beim Alloc/Get und Free, aber dieser kann nicht wirklich in die Bewertung der MemoryManager einbezogen werden, da dieser eher unregelmäßig auftritt und aus der Struktur der internen Speicherwerwaltung resultiert.


Oberhalb der 2 KB sind der FastMM und mein FastXMM etwa gleich ausgelegt und unterscheiden sich dirnt nicht all zu sehr, was das Tempo angeht.


Einen weiter Vorteil gegenüber Delphi MM ist bei den Fast(X)MM, daß man halt einen besseren Einblick in die Arbeit des MMs hat - z.B. über die MemoryMap.



Allerdings gibt es bei meinem FastXMM noch etwas zu beachten. (dieses Gild allerdings nicht für die hier hochgeladene "Single Unit"-Version)
Und zwar kann man (zukünftig) meinen MM in einem speziellen Modus betreiben, welcher es erlaubt die Speicheroptimierung für jede Speicheranfrage(Get/Realloc/Free) einzeln einzustellen.
Im Moment ist diese Optimierungsmöglichkeit allerdings nur bei der Stringbehandlung in meinem UCC enthalten, dieses wird aber demächst dort entfernt und direkt in den MM eingefügt.
Und zwar kann man dem MM dann mitteilen, wie diser auf eine Größenänderung reagieren soll. Es ist dann also möglich die Speicherverwaltung speziell an die Bedürfnisse des Programms anzupassen, so daß man theoretisch (bei häufigen Änderungswünschen per Realloc) eine Geschwindigkeiststeigerung innerhalb des reallocs von bis zu 99% erreichen kann.