RTL Performance D7 vs XE7

[Bernhard Geyer]

Zitat:

Zitat von Stevie (Beitrag 1272273)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1272270)

Oder vergleichst du jetzt Anis mit Unicode-String?

Nicht Anis, sondern Salbei...

Bin eher für Kümmel ... :-)

Zitat:

Zitat von Stevie (Beitrag 1272273)

Natürlich tu ich das. Denn genau das passiert, wenn du deine Software mit

Delphi-Quellcode:

string

in Delphi 2007 oder eher geschrieben hast und migrierst.

Eigentlich steht bei uns fast nur unser "OwnString"-Typ überall drin. Unter D6 (noch Haupt-IDE) ist es auf Widestring gemappt und unter XE6 (wird gerade portiert) ist es dann (Unicode-)String.

[himitsu]

[QUOTE=Bernhard Geyer;1272270]

Zitat:

Zitat von Stevie (Beitrag 1272266)

Zitat:

Zitat von mkinzler (Beitrag 1272262)

Der Punkt ist, dass bis Delphi 2009 einige

Delphi-Quellcode:

string

Geschichten schneller liefen, weil der Compiler da kein Zeugs für Unicode Kompatibilität zwischengehauen hat.

Und was soll er da dazwischen hauen? Oder vergleichst du jetzt Anis mit Unicode-String?

Einen Teil des krankenhaften StringChecking hat man zwischenzeitlich wieder ausgebaut.

[newbe]

Zitat:

Was soll man denn da interessantes und alltagstaugliches benchmarken?

Tja also was mich da konkret interessieren würde, wäre zum Beispiel die ganze Arbeit mit normalen Objekten. Sprich Erzeugung und Zerstörung, Listen und Objectlistenhandlung (add, insert, Remove, Delete, Objectsuche), Performance bei Verwendung der neuen Generics vs altes Casting, wie sind dort die Perf. Gewinne bzw. Verluste. Iteration über große Listen. Floating Point Performance is für mich eher Sekundär, aber Stringhandling äußerst wichtig. Verwende viele Stringlisten und Indexof. Performance von D7 string native vs Faststringprojekt vs XE7 Stringhandling. Auch die Performance des alten D7 MM vs XE7 MM Perf. Hier speziell der Listeninsert und die Listenerweiterung.

nur mal einiges was ich gern wissen täte :)

mfg newbe

[Stevie]

Zitat:

Zitat von newbe (Beitrag 1272295)

Zitat:

Was soll man denn da interessantes und alltagstaugliches benchmarken?

Tja also was mich da konkret interessieren würde, wäre zum Beispiel die ganze Arbeit mit normalen Objekten. Sprich Erzeugung und Zerstörung, Listen und Objectlistenhandlung (add, insert, Remove, Delete, Objectsuche), Performance bei Verwendung der neuen Generics vs altes Casting, wie sind dort die Perf. Gewinne bzw. Verluste. Iteration über große Listen. Floating Point Performance is für mich eher Sekundär, aber Stringhandling äußerst wichtig. Verwende viele Stringlisten und Indexof. Performance von D7 string native vs Faststringprojekt vs XE7 Stringhandling. Auch die Performance des alten D7 MM vs XE7 MM Perf. Hier speziell der Listeninsert und die Listenerweiterung.

nur mal einiges was ich gern wissen täte :)

mfg newbe

Fällt imo alles in die Kategorie "muss man sich keine Sorgen drum machen". Weitaus wichtiger ist, dass dein Code vernünftig ist. Gerade was Listen angeht, kann man sich derbst ins Bein schießen, was Performanceverschwendung angeht. Letztens erst wieder Code refactored, wo jemand 3mal ne Liste durchgeeiert ist, wo auch einmal gereicht hätte. Bumms, 200% Performancegewinn. Anderes Beispiel, Stringlisten. Wird gern als des armen Manns Hash benutzt. Wenn man da z.b. nicht

Delphi-Quellcode:

Sorted := True

gesetzt hat, dann wird bei IndexOf einfach ne lineare Suche gemacht, ansonsten eine binäre. So kann man auch Performance zum Fenster rauswerfen.

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

Zitat von newbe (Beitrag 1272310)

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