FastMM grotten langsam ?!

[stoxx]

Jetzt hab ich gehört, dass FastMM doch sooo viel besser sein soll, als der Borland Speichermanager.
Habe D2005.

Jetzt habe ich also probiert: http://sourceforge.net/projects/fastmm/

und auch gleich mal getestet, und oh Schreck, mit FastMM braucht der Vorgang doppelt so lange.
Mit Original Borland Speichermanager etwa 3000 ms und mit FastMM rund 6000 ms
Liegt das an meinen fehlenden Kenntnissen über FastMM und dessen Optionen oder ist das einfach nur verarsche ?
Wie sieht das bei Euch aus ?

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
const ende = 50000000;
type
      tar = array  of double;

var i, a : longint;
    p: tar;
    c, start, stop, merke : tlargeinteger;

begin

application.processmessages;


queryperformancefrequency(c);
queryperformancecounter(start);

// Speicherreservierung  + Schreiben
i:=0;
while i<=ende do
begin
  if i mod 10 =0 then setlength(p,i+10);
  //setlength(p,i+1);
  p[i] := 5000;
  inc(i);
end;// von vor

queryperformancecounter(stop);
merke:=stop-start;


// Durchlauf  nur Schreiben
queryperformancecounter(start);
i:=1;
while i<ende do
begin
  p[i] :=6000.50;
  inc(i);
end;

queryperformancecounter(stop);

Showmessage('Mit Speicherreservierung: ' +  format('%.2f ms', [merke/c * 1000]) +#13#10 +
             'Durchlauf Schreiben : ' +  format('%.2f ms', [(stop-start)/c * 1000]));





end; // dynamisches Array

[himitsu]

Also extrem viel schneller ist es auch nicht ... aber meißtens sollte es schneller sein, aber eben nicht immer

Du könntest es ja mal unter den selben Bedingungen hiermit mit meinem MemoryManager versuchen.
Der is 'ne Abart des FastMM und arbeitet ein klein wenig anders ^^

Ein-/Verstellen brauchst du auch nichts, mußt halt nur die FastXMM.pas als erstes in die Uses-Klausel deiner DPR einfügen.


PS: als Extrem kannst du es ja mal in Einerschritten versuchen, also das SetLength bei jedem Durchgang aufrufen.
setlength(p,i);

Ach ja, das "Durchlauf nur Schreiben" kannst du dir sparen, denn die MemoryManager verwalten ja nur den Speicher, also das reservieren, Größe ändern und freigeben.

Am Schreib-/Lesezugriff wird also nichts verändert.

[jim_raynor]

Problem könnte ja sein, dass FastMM zwar schneller ist, dafür aber mehr Arbeitsspeicher zur Verwaltung braucht. Eventuell verursacht dieser Mehrverbrauch ein häufiges Auslagern des Speichers wodurch es natürlich langsamer wird.

[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.

[himitsu]

Zitat von jim_raynor:

Problem könnte ja sein, dass FastMM zwar schneller ist, dafür aber mehr Arbeitsspeicher zur Verwaltung braucht. Eventuell verursacht dieser Mehrverbrauch ein häufiges Auslagern des Speichers wodurch es natürlich langsamer wird.

Es ist natürlich klar, das Fast(X)MM mehr speicher benötig, denn gerade dadurch wir schließlich die Gewschwindigkeitssteigerung erzeugt (wenn man das so nennen kann).

Und aktuell ist es so, daß der Speichermehrverbrauch beim bis zu 3-Fachen des tatsächlich benötigten liegen kann, allerdings liegt im großen Durchschnitt der reelle Mehrverbrauch bei etwa 5-10%, was bei normalen Anwendungen und ausreichend RAM kaum zu einer verstärkten Auslagerung des Speichers führen sollte.

Wenn aber dennoch Speicherbereiche ausgelagert sind, dann wird sich die Geschwindigkeitssteigung durch Fast(X)MM eventuell sogar noch verstärken (habs noch nich getestet), da ja die Veränderungen im Speicher (welcher bei Windows reserviert wurde) stark minimieren.


[add]Ach ja, wie breits gesagt wird sich eine Geschwindigkeitssteigerung nur vorwiegend bei kleinen Änderungen zeigen.
Du änders den Speicher aber um jeweils um 10 Schritte, also 80 Byte (10 mal 8 Byte pro Double), was bedeutet, das sich in den ersten Durchläufen (wenn das Array noch kurz ist), sich kaum/keine Verbesserung einstellen wird und slbst später wird sich die Verbesserung eigentlich nicht so sehr zeigen, denn im Grunde genommen hast du ja selber schon eine "kleine" Speicheroptimierung eingebaut,
if i mod 10 =0 then setlength(p,i+10); wodurch du aber wiederum einige Vorteile von FastMM ausgehebelt hast

[stoxx]

Hallo Himitsu,

es ist natürlich so, dass ich nur die Hälfte von dem verstehe, was Du schreibst, da ich bei Speichermanagern nicht wirklich so der Fachmann bin.
FastMM ist bei Verwendung von TList im obigen Beispiel etwa 10 Prozent schneller als Delphi.
Der Vorteil verschwindet aber, wenn FastMM bei anderen Anwendungsfällen gleich um das Doppelte einen Ausreißer ins Negative hat.

Zitat:

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.

das wäre jetzt irgendwie interessant. und was bedeutet das ? .. hehe

Eine Sache hab ich bei den Speichermanagern noch nicht verstanden, wenn ich ein Dynamisches Array habe, ist dieser Speicher auch wirklich dann zusammenhängend ?
Was passiert in dem Fall, wenn das Array eine Größe von 1000 hat und dann irgendwo anders Speicher benötigt wird ,und wenn dann danach das Array auf 1001 vergrößert wird. Wird dann alles umkopiert ?
Könnte es im Extremfall passieren, dass die ersten 1000 Elemente an eine neue Stelle kopiert werden ?
Ich arbeite im Moment noch mit Listen, würde aber gern auf Arrays umsteigen, meine tests haben aber ergeben, dass bei einer großen Anzahl von Elementen das irgendwie langsamer ist. Leider stören mich der Platz der vielen Zeiger ...

naaja ..

[himitsu]

Zitat von stoxx:

es ist natürlich so, dass ich nur die Hälfte von dem verstehe, was Du schreibst, da ich bei Speichermanagern nicht wirklich so der Fachmann bin.
FastMM ist bei Verwendung von TList im obigen Beispiel etwa 10 Prozent schneller als Delphi.
Der Vorteil verschwindet aber, wenn FastMM bei anderen Anwendungsfällen gleich um das Doppelte einen Ausreißer ins Negative hat.

Eigentlich sollte es nicht so sein, daß die Speicherverwaltung in einigen Fällen extrem verlangsamt wird.
Obwohl es natürlich möglich wäre, daß eine Verlangsamung auf Grund der anderen Art der Speicherverwaltung auftritt. (es wird halt etwas mehr gerechnet, um so optimaler zu arbeiten)

Obwohl ich nicht hoffe, daß es auch bei meinem MM so ist ._. (hast du es auch mal damit versucht)
Und wenn, würde ich mir dieses Verhalten, bei Zeiten, nochmals genauer ansehn und prüfen was sich da machen ließe ^^

Zitat von stoxx:

das wäre jetzt irgendwie interessant. und was bedeutet das ? .. hehe

Im Grunde ist es so, daß man (im Moment nur bei den Stringfunktionen meines UCCs) zusätzlich angeben kann in welchen Intervallen die Speicherreservierung für Strings arbeiten soll.

Dazu gibt es dann folgende Konstanten:

Delphi-Quellcode:

Type SLType = Type LongInt;  // The OLE-WideString supported only slReal and slUnique is always set.

Const slReal  = ...;
  slUpDown_1  = ...;    slOnlyUp_1  = ...;  // 0,1 KB /     128 B
  slUpDown    = ...;    slOnlyUp    = ...;  //   1 KB /    1024 B
  slUpDown10  = ...;    slOnlyUp10  = ...;  //  10 KB /   16384 B
  slUpDown100 = ...;    slOnlyUp100 = ...;  // 100 KB /  131072 B
  slUpDown1M  = ...;    slOnlyUp1M  = ...;  //   1 MB / 1048576 B

  slSetNew    = ...;
  slZeroNew   = slSetNew or Ord(#0);
  slSpaceNew  = slSetNew or Ord(' ');

  slUnique     = SLType($00200000);
//slThreadSave = SLType($00800000);

Mit slReal (ist natürlich der Standard, wenn man nichts angibt) bleibt alles so wie es bisher ist.
Über slUpDown... wird der Speicher immer nur in Schritten eines bestimmten Wertes reserviert und mit den slOnlyUp... kann zusätzlich noch verhindert werden, daß Speicher freigegeben/verkleinert wird.

Wenn man z.B. einen String hat, dessen Größe sich sehr oft (vorzugsweise in kurzer Zeit) über einen weiten Bereich verändert, dann kann man z.B. über die Angabe von slOnlyUp1M dafür sorgen, daß tatsächlich ständig Speicher freigegeben und reserviert wird. (einzig bei S := ''; oder einem SetLength auf 0 wird immer der Speicher, unabhängig vom Parameter, freigegeben, dieses hängt aber mit der Definition der Strings zusammen)
Es ist ja so, daß die Fast(X)MM vorwiegend ihre Vorteile nur bei kleiner Veränderungen können und bei "extrem" Großen nicht verbessern ausspielen.

Es haben alle alle Funktionen/Prozeduren zur Stringbehandlung (wenn es erforderlich ist) einen weiteren Parameter. (was ich ja auf weitere Bereich ausweiten möchte)
z.B.
Procedure _SetLength(Var S: AnsiString; Len: LongInt; Typ: SLType = slReal); Abgesehn davon hab ich mir auch noch weitere Optimierungen einfallen lassen, was das Tempo steigern kann
z.B.

Delphi-Quellcode:

Function _StringReplace(Const S, OldPattern, NewPattern: AnsiString; Flags: TReplaceFlagsEx; Typ: SLType = slReal): AnsiString;
Procedure StringReplaceV(Var S: AnsiString; Const OldPattern, NewPattern: AnsiString; Flags: TReplaceFlagsEx; Typ: SLType = slReal);

Zweiteres wird also schneller sein, da dort nach der Funktion nich erst der als String freigegeben und durch den Neuen ersetzt werden muß, da ja der String direkt verändert wird.

Delphi-Quellcode:

S := _StringReplace(S, 'alt', 'neu', [rfeReplaceAll]);
StringReplaceV(S, 'alt', 'neu', [rfeReplaceAll]);

Zitat von stoxx:

Eine Sache hab ich bei den Speichermanagern noch nicht verstanden, wenn ich ein Dynamisches Array habe, ist dieser Speicher auch wirklich dann zusammenhängend ?

Also, die Daten in einen Array sind immer zusammenhängend, man kann sich also ohne Probleme z.B. einen Pointer auf des ersten Eintrag, oder einen anderen besorgen und dann ohne weiteres auf die darauffolgenden, oder eventuell auch vorherige Einträge direkt zugreifen,, da sie ja wirklich im Speicher genau hintereinander liegen (mal abgesehn davon, das Aufgrund der Speicherausrichtung die Elemente in einem anderem Abstand angeordnet sind, siehe PACKET).
Es muß also Aufgrund der zsammenhängenden Datenstruktur immer ein zusammenhängender Speicherbereich reserviert werden.
Und zumindestens Fast(X)MM versuchen zuerst den nachfolgenden Speicher zu reservieren und wenn dieser schon belegt ist, dann muß halt der gesamte Speicher (z.B. die Arraydaten) verschoben/kopiert werden.

PS: die Listen verbrauchen ja nicht nur durch die vielen Zeiger mehr Platz. Es muß ja auch (unter Umständen, weiß ja nicht wie alle Listen arbeiten) für die einzelnen Elemente ein eigener Speicherbereich reserviert werden und pro Speicherbereich werden ja auch noch bestimmte Verwaltungsdaten (im MemoryManager) benötigt.

[md_mse]

Huhu...

FastMM scheint in den meisten Fällen tatsächlich schneller zu sein als der Borland MM, jedoch habe ich bessere Erfahrungen mit RecyclerMM, welcher vor allem für Multi-Threaded Anwendungen optimiert ist, machen können...

Kann es jedem nur empfehlen: RecyclerMM

[himitsu]

Hab mal 'nen kurzen Blick in den RecyclerMM geworfen.

Zitat:

vor allem für Multi-Threaded Anwendungen optimiert

So wie das aussieht wüste ich gern, was daran speziell für MultiThread besonders sein soll?

Außerdem scheint der wohl nicht ganz platzsparend zu sein ... mir sind da schon auf den ersten Blick einige Dinge aufgefallen, welche wohl bei normalem Betrieb (vorallem ohne Nutzung des UsageSnapShots/UsageTrackers) einiges an Speicher und Rechenzeit verschwenden.

Die Speicherverwaltung der kleineren SpeicherBlöcke halte ich beim FastMM für optimaler - von der Speicherausnutzung her.


Und wenn der läuft will ich lieber nichts all zu Schlechtes über den RecyclerMM sagen - irgendwo hat sicher jeder MM seine Vor- und Nachteile.
Aufgrund von Hagens Aussage revidiert.



Aber die Einbeziehung der Rechenzeit in den UsageBenchmark find ich nicht schlecht ... werd' mal sehn, ob ich das bei mir auch mit mache - die Aufrufe werden ja bei mir eh schon mitgezählt, wenn auch in einer etwas ausführlicheren Form (nicht in der SingleUnit-Version)

[negaH]

Kurz: RecyclerMM ist Schrott ! lass die Finger davon.

Gerade das angepriesene Multithreading ist tödlich. Denn RecyclerMM kann niemals korrekt erkennen wann ein Thread terminiert wird und dies führt dazu das die zu diesem Thread allozierten Speicherbereich nicht mehr fregegeben werden können.

Besonders in ActiveX, COM etc. pp. Anwendung sind solche extern allozierten Threads vorhanden. Bedenke ja das der eigene Prozess ja nur ein COM Service ist der die COM Anforderungen externer Prozesse erfüllen muß. Wird nun in diesem COM Objekt zb. mit LongStrings gearbeitet so alloziert RecyclerMM Speicherresourcen die er nicht mehr freigeben kann. Denn RecyclerMM kann keine Kontrolle darüber haben wann nun der externe Thread tatsächlich beendet wird.

Gruß Hagen