So nun konzepionell:
Es gibt mehrere Wege einen MM zu "optimieren".
1.) man alloziert ständig mehr Speicher auf Verdacht um im eventuell späteren Falle einer Reallokation sofort diese Anforderung erfüllen zu können.
2.) man ändert die Strategie der Verwaltung der freien Speicherblöcke um später dann gezileter und schneller eine Speicheranforderung erfüllen zu können.
3.) man optimiert den Sourcecode indem man schneller Assemblerfunktionen benutzt.
Nur Punkt 2.) ist eine echte Altrnative und in FastMM4 auch das primäre Optimierungsziel gewesen. Nur 2.) optimiert den Algorithmus ansich und bietet somit das meiste Potential.
Punkt 3.) kann nur ein Fein-Tuning darstellen.
Punkt 1.) ist eher gefährlich als nützlich. Aber gerade Punkt 1.) wird bei den meisten sogannenten "besseren" MM's benutzt. Was ist daran aber so gefährlich ?
Ok, RecyclerMM: dieser übertreibst mit Punkt 1.) und im WorstCase betrachtet bedeutet dies: Allozieren für jede Speicheranforderung immer wieder komplett neuen Speicher. Bei der Deallokation dieser Speicher spare die komplette Zeit ein indem du diesen Speicher garnicht mehr freigibst !!! Man kann sich nun leicht ausrechnen was passieren muß.
Aber exakt so geht RecyclerMM vor. Ok, er optimiert indem er übergroße Speicherblöcke alloziert, quasi die Speicheranforderung höher auslegt als benötigt. Die Wahrscheinlichkeit diese preallozierten Überhangs im vergleich zu dann tatsächlichen Auslastung wird immer schlechter je größer dieser Überhang ist.
Jetzt stellen wir uns mal vor ALLE Programme würden solche MMs benutzen !? Dann würden nur 3 Prozesse immer mehr an Speicher verbrauchen diesen aber eben nicht effektiv nutzen.
Ergo: ein guter Speichermanager wird nicht nur schnell Speicher allozieren können, nein, viel wichtiger ist es das er auch diesen Speicher immer wieder auch an das
OS freigibt wenn er nicht mehr benötigt wird. Denn nur so eine Strategie kann dazu führen das nicht die eigenen Anwendung nur deshalb schneller wird weil sie den anderen Anwendungen den Speicher wegnimmt/blockiert.
Schaut man sich FastMM4 genauer an so erkennt man wodurch er ca. 2 mal schneller als der Borland MM wird.
1.) viele Sourcen nutzen Assembler bzw. sind besser durch den Compiler optimierbar. Ein Umschreiben des Borland MMs nach dieser Taktik wird den Borland MM auch ca. 50-60% beschleunigen können.
2.) der Rest des Performancegewinnes liegt darin begründet das die Granulatät des FastMM4 höher ist als die ses Borland MMs. D.h. FastMM4 kann viel exakter entscheiden und geordeneter auf spezifische Speicheranforderungen reagieren als der BorlandMM. FastMM4 benutzt quasi ein leicht optimaleren Algorithmus.
Gruß Hagen