RTL Performance D7 vs XE7

[himitsu]

Der FastMM kann InPlace-Realocations, also verkleinern/vergrößern, ohne daß der alte Speicherblock verschoben werden muß.
Vorallen bei größeren Speicherblöcken und wenn dahinter genug Platz ist.

Das alte FastStringsProjekt wurde teilweise ins Delphi übernommen (irgenwann um/nach 2006).

Generics sollte nicht schneller sein, als die nicht-generische Variante, bzw. gleich schnell.
Im Prinzip sind dort "nur" die manuellen Casts durch automatische ersetzt, wobei damit der Compiler besser für Typsicherheit sorgen kann.

Bei Listen, also vorallem wenn dir die Sortierung egal ist, wären die TDictionary<T>'s ein Überlegung wert, da sie eine optimalere Suchfunktion besitzen, als z.B. die TStringsList.
Insgesamt hat man die generischen Listen oftmals um Hashlisten, Binäre suchen und Dergleichen aufgemotzt, was die alten Funktionen nicht immer hatten.

[newbe]

@stevie

dachte sortet is bei TStringlist standardmäßig auf true? bin jetz leicht verwirrt.

mfg

[Stevie]

Zitat von newbe:

@stevie

dachte sortet is bei TStringlist standardmäßig auf true? bin jetz leicht verwirrt.

mfg

Wat? Nö, dann würden ja neue Einträge nicht hinten angehangen werden sondern alphabetisch eingeordnet.

[newbe]

achja stimmt... ich bin auch durch für heute

[jbg]

Zur Klarstellung: Der FastMM für Delphi 7 stammt nicht von mir und ich baue den auch nicht über DelphiSpeedUp ein. Die BorlndMM.dll muss man schon selbst austauschen.

Zitat:

Generics sollte nicht schneller sein, als die nicht-generische Variante, bzw. gleich schnell.

Wohl eher langsamer, da sie nun mal keine Templates sondern Generics sind und man somit z.B. bei IndexOf nicht "if FList[Index] = Value then" schreiben kann, sondern einen Comparer (Interface) bemühen muss "if Comparer.Equals(FList[Index], Value)", was ein indirekter Funktionsausruf ist, der dem Compiler auch noch die Möglichkeit nimmt, Daten in CPU Register zu bunkern, vor allem bei Win32.
An die Geschwindigkeit einer TList kommt TList<T> bei weitem nicht ran.
Beispiel Worst-Case Szenario: 100.000 Einträge, letztes Element muss 10.000 Mal gefunden werden

Code:

TList: 0.299 Sekunden
TList<T>: 1.870 Sekunden

Zitat:

Bei Listen, also vorallem wenn dir die Sortierung egal ist, wären die TDictionary<T>'s ein Überlegung wert, da sie eine optimalere Suchfunktion besitzen, als z.B. die TStringsList.

Da habe ich gerade ein tolles Beispiel, bei dem die Daten so beschaffen sind, dass die binäre Suche von TStringList (mit überschriebener CompareString Funktion auf "Result := CompareStr(S1, S2);" ) fast doppelt so schnell ist, wie das TDictionary. Die Strings sind mehr als 10.000 GUIDs, die fast 1.000 Mal abgefragt werden.

Code:

StringList Find: 1.993 Sekunden
Dictionary TryGetValue : 3.983 Sekunden

Und das auf meinem nagel neuen PC. Im Büro habe ich eine um weiten langsamere Kiste stehen.

Die Zeit, die beim Laden der Daten drauf ging hat sich durch die Umstellung von TDictionary auf eine CompareStr-StringList halbiert. Es dauert zwar immer noch zu lange, aber das ist schon mal ein Anfang. Gut, die Daten sind für das TDictionary etwas ungünstig, aber zum Glück gibt es noch die gute alte TStringList. Die Lösung wird wohl sein, die GUIDs in 2 Int64 zu konvertieren und dann eine "handgeschriebene" Dictionary Klasse zu schreiben, vor allem mit dem Hintergrund, dass die 10.000 Daten nur die Spieldaten sind (ob uns da nicht die GUIDs ausgehen )

[himitsu]

Ach mist, der blöde Vergleicher.

Die sind nicht so gut und optimieren das z.B. für Strings/Integer?

Jetzt muss ich nochmal nachsehn, ob die for-in-schleife bei Arrays und Strings auch über die Enumeratoren läuft.

[Stevie]

Zitat von himitsu:

Jetzt muss ich nochmal nachsehn, ob die for-in-schleife bei Arrays und Strings auch über die Enumeratoren läuft.

Nein, tut sie nicht.

[Stevie]

Zitat von jbg:

Wohl eher langsamer, da sie nun mal keine Templates sondern Generics sind und man somit z.B. bei IndexOf nicht "if FList[Index] = Value then" schreiben kann, sondern einen Comparer (Interface) bemühen muss "if Comparer.Equals(FList[Index], Value)", was ein indirekter Funktionsausruf ist, der dem Compiler auch noch die Möglichkeit nimmt, Daten in CPU Register zu bunkern, vor allem bei Win32.
An die Geschwindigkeit einer TList kommt TList<T> bei weitem nicht ran.
Beispiel Worst-Case Szenario: 100.000 Einträge, letztes Element muss 10.000 Mal gefunden werden

Code:

TList: 0.299 Sekunden
TList<T>: 1.870 Sekunden

Ich nehm mal an, dass du als T eine Klasse genommen hast. Da ist nämlich das Verhalten von TList und TList<T> ein bisschen unterschiedlich und daher auch zusätzlich zu dem IComparer Overhead langsamer: TList macht einfach nen stumpfen Pointervergleich. Der Comparer bei Objekten ruft TObject.Equals auf. Und das kann sehr wohl überschrieben sein, so dass man dort nich einfach Referenzen vergleichen kann.

[jbg]

Zitat von Stevie:

Ich nehm mal an, dass du als T eine Klasse genommen hast.

Falsche Annahme. Ich habe TList und TList<Pointer> benutzt. Es sollen ja gleiche Regeln gelten.

[newbe]

@jbg

vielen Dank für deine interessanten Ausführungen. Deine beschriebenen Caseszenarien liegen glaub ich eher bei den meinen. Hinzu kommt noch das ich Lazy Loading nicht besonders mag und vermeide wenn ich die Möglichkeit habe. Es komm also häufiger Vor das ich beim initialisieren des Programms
Objectlisten mit mehreren Tausend Objekten pro Typ vollballere. Und da kommt es dann doch schon auf solche "Kleinigkeiten" an.

auch meine ich damals mal gehört zu haben das der Borland MM beim erweitern von Listen schneller sein sollte, weil er imm gleich 4 einträge allociert der FastMM immer einen einzigen. Trifft dies noch immer so zu?

mfg newbe