RTL Performance D7 vs XE7

[newbe]

Hallo allerseits,

Ich weis aus der Vergangenheit das es nach Delphi XE2 Performanceprobleme mit der RTL gab.
Gibt es dort schon gute Benchmarkvergleiche mit XE7? Vielleicht hat sich da ja was getan?
Mich interessiert aber nur die Performance im Zusammenhang mit der VCL. Alles was es sonst noch gibt wie Crossplattform bzw. FMX, Firemonkey, Mobil Nextgen Compiler verwende ich nicht und ist deshalb nicht interessant für mich. Wäre nett wenn jemand paar gute Quellenlink für mich hätte.

Achja noch eine kleine Frage zum XE7 Mobilpart. Werden dort jetzt die jeweils nativen Controls des OS genutzt, oder immernoch die Akkuzeitfressenden Firemonkey-Pendants?

mfg newbe

[mkinzler]

Performance von Delphi XE6:
http://riversoftavg.com/blogs/wp-con...010-to-XE6.pdf

Grundsätzlich wird die Version mit Vektorgrafik verwendet. Es gibt es aber schon 2 Komponenten, welche man auf nativ umstellen kann; leider bisher nur für iOS ( bei anderen Plattformen wird die Einstellung ignoriert.)

[Der schöne Günther]

Was soll man denn da interessantes und alltagstaugliches benchmarken?

Die XE7-Demo ist frei verfügbar, du kannst doch selbst ganz konkret testen, was dich interessiert. Mir würde es jetzt an Fantasie fehlen, was man denn hier konkret testen soll. Und wo es überhaupt angeblich "Probleme" geben kann...

[Stevie]

Zitat:

Zitat von Der schöne Günther (Beitrag 1272256)

Was soll man denn da interessantes und alltagstaugliches benchmarken?

Was man alles benchmarken kann, ist nicht so schwer, nur was davon man nun für sich als wichtig betrachtet ist eher die Frage.
Den einen interessiert Numbercrunching mit Floats, den nächsten String Handling. Und ein weiterer muckiert sich über fehlende Return value optimization bei gemanagten Typen. Man müsste da schon etwas konkreter sein.

Im übrigen liegen nicht alle Dinge im Code der RTL begründet, die nun wegen Multiplatform an einigen Stellen nicht mehr Assembler Code nutzt sondern Pure Pascal, sondern auch im Compiler (wie z.B. die RVO)

[Bernhard Geyer]

Gegenüber D7 mit dem Widestring ist XEx mit dem Unicodestring um Welten schneller.

[mkinzler]

Der UnicodeString ist auch von Delphi verwaltet. Der war sicherlich auch schon unter XE2 schneller als WideString. 8-)

[himitsu]

WideString ist eine Kapselung von SysAllocStr und Co.

UnicodeString ist, wie der AnsiString, ein LongString, was intern einem aufgemotzem dnamischen Array entspricht.
* mir Referenzzählung, während der WideString nur eine Referenz kennt und jedesmal kopiert wird
* und über den Delphi-Speichermanager verwaltet

Wobei mit Delphi 2006? auch noch der SpeicherManager vom Delphi duch FastMM ersetzt wurde.



Herr Hausladen hat sogar ein Pugin, womit der MM der D7-IDE durch FastMM ersetzt wird, womit diese auch gleich mal flotter wird.

[Stevie]

Zitat:

Zitat von mkinzler (Beitrag 1272262)

Der UnicodeString ist auch von Delphi verwaltet. Der war sicherlich auch schon unter XE2 schneller als WideString. 8-)

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.

[Bernhard Geyer]

[QUOTE=Stevie;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?

[Stevie]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1272270)

Oder vergleichst du jetzt Anis mit Unicode-String?

Nicht Anis, sondern Salbei...

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

Delphi-Quellcode:

string

in Delphi 2007 oder eher geschrieben hast, migrierst und dann irgendwelche Performance Tests laufen lässt, die Stringoperationen beinhalten.
Dass das Äpfel mit Birnen vergleichen ist, weiß ich, aber manche nicht. Deshalb erwähn ichs nochmal.

P.S. FPC is eh viel schneller! /sarcasm off :roll:

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

[Stevie]

Zitat:

Zitat von himitsu (Beitrag 1272321)

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:

Zitat von jbg (Beitrag 1272317)

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:

Zitat von Stevie (Beitrag 1272328)

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

[Stevie]

Zitat:

Zitat von jbg (Beitrag 1272335)

Zitat:

Zitat von Stevie (Beitrag 1272328)

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.

Naja, für Pointer eine generische Liste zu benutzen ist auch ziemlich witzlos.

[jbg]

Zitat:

Zitat von newbe (Beitrag 1272364)

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?

Das ist nicht Sache des Speichermanagers, sondern der Liste. Und die macht das immernoch so, wie zu Delphi 1.0 Zeiten. Der FastMM (der in der BorlndMM.dll seit Delphi 2006 sitzt) reserviert beim Vergrößern (Realloc) ein wenig mehr Platz, so dass ein weiteres Vergrößern ohne Anfordern von mehr Speicher erfolgen kann, was das ganze stark beschleunigt und bedingt auch die Speicherfragmentierung etwas verringert.

Zitat:

Zitat von Stevie (Beitrag 1272366)

Naja, für Pointer eine generische Liste zu benutzen ist auch ziemlich witzlos.

Ich hätte auch Integer/NativeInt nehmen können und es würde für TList<Integer> genauso schlecht aussehen. Ich wollte mir nur die Typecasts von Pointer->Integer bei TList sparen und zwei gleiche Listentypen vergleichen.
Und zum TList<TObject>. Wer überschreibt in Delphi denn TObject.Equals? Das führt nur zu seltsamen Effekten, da das es zu spät kam und jeder davon aus geht, dass ein List<TObject>.IndexOf(MyObject) den Index von MyObject liefert und nicht von einem Objekt, dass zufälligerweise die selben Daten hat.

[Stevie]

Zitat:

Zitat von jbg (Beitrag 1272371)

Wer überschreibt in Delphi denn TObject.Equals? Das führt nur zu seltsamen Effekten, da das es zu spät kam und jeder davon aus geht, dass ein List<TObject>.IndexOf(MyObject) den Index von MyObject liefert und nicht von einem Objekt, dass zufälligerweise die selben Daten hat.

Nunja, TObject.Equals wird beim IEqualityComparer benutzt. Bei TList<T>.IndexOf wird aber der beim Create übergebene (oder der default) IComparer benutzt. Der kann aber durchaus auf irgendwelche Eigenschaften eines Objekts gehen (weil er auch für die Sortierung benutzt wird. Wenn ich also nen naiven Comparer baue, der nach Nachnamen und Vorname sortiert, bekomm ich bei IndexOf den ersten Hans Müller aber nicht exact denselben. Imho ein Designfehler (in Spring4D und in .Net sowieso wird der default IEqualityComparer dafür benutzt).
Wenn du das optimieren willst, dann musst du dir die IndexOf Methode überschreiben und dort mir einem case über den TypeKind die spezifischen Vergleiche laufen lassen (so werd ich diese Optimierung wohl auch in Spring4D einbauen, von daher an dieser Stelle danke, dass du mich auf dieses potenzielle Performanceproblem aufmerksam gemacht hast)

Im Übrigen benutzen wir Equals overrides bei Datenklassen durchaus (meist läuft es auf ein Id Vergleich hinaus).

[newbe]

@jbg

Der FastMM ist jetzt doch drinne in XE7 oder?

@stevie

Mir ginge es beim verwenden von generics um das weniger Code schreiben / mehr Lesbarkeit, jedoch bin ich nicht gewillt dafür derartige Performanceeinbußen hinzunehmen. Den Zugriff über irgendwelche Enumeratoren find ich auch schlecht gelöst. Wenn dann bitte so wie in C#

also in der Art

foreach var item in items
item.machirgendwas;

oder

for (int i = 0; i < items.count();i++)

bla = items[i];
bla.mache irgendwas;

mfg newbe

[Stevie]

Zitat:

Zitat von newbe (Beitrag 1272375)

@stevie

Mir ginge es beim verwenden von generics um das weniger Code schreiben / mehr Lesbarkeit, jedoch bin ich nicht gewillt dafür derartige Performanceeinbußen hinzunehmen. Den Zugriff über irgendwelche Enumeratoren find ich auch schlecht gelöst. Wenn dann bitte so wie in C#

also in der Art

foreach var item in items
item.machirgendwas;

Häh? Hast du überhaupt ne leise Ahnung, wie ne foreach Loop in C# funktioniert?
Richtig, mit nem Enumerator.

Worin unterscheidet sich das von:

Delphi-Quellcode:

for item in items do
  item.machirgendwas;

Außer, dass eine for in Schleife in Delphi bei einem Array (im Gegensatz zu C#, wo auch ein array IEnumerable implementiert) nicht über einen expliziten Enumerator läuft sondern vom Compiler direkt übersetzt wird.

[newbe]

@stevie

naja ich kanns nicht so schreiben??? Wenn ich deinen Post vorhin richtig verstanden habe muss ich
auf das Item über irgendwelche comperator Interfaces drauf zugreifen?

dat hier meinte ich

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.

der Unterschied fällt dir auf? gerade geschachtelte Liste und Array Acessoren finde ich hässlich.

mfg newbe

[Dejan Vu]

Ich würde bezüglich der allgemeinen Performanceüberlegungen noch gerne anmerken, das weder eine Listenimplementierung, noch die Frage, ob generisch oder nicht, noch die Frage, wie oft man eine Liste durchläuft, bezüglich der Performance entscheidend ist, sondern einzig und alleine bzw. vorrangig die Wahl der richtigen Datenstruktur bzw. des richtigen Algorithmus.

Es gibt kaum Anwendungen, die performancetechnisch ein Problem darstellen, wenn man die richtigen Datenstrukturen wählt). Ausnahmen sind hier z.B. Numbercruncher, wie Mandelbrot z.B. oder ähnliches. Natürlich lassen wir die Palette der Programme mal außen, vor, die eh nur Däumchen drehen, weil sie auf eine überlastete Platte oder das dämlich lahme "Breitbandnetz" warten...

In einer Liste suchen gehört mit Sicherheit nicht dazu. Wenn ich hier ein Performanceproblem sehe, dann nehme ich etwas anderes: Trivial eine sortierte Liste und suche nicht linear, sondern binär. Besser, eine Dictionary, die sucht noch nicht einmal mehr binär, sondern weiß quasi, wo was zu finden ist.

Ich will jetzt nicht auf dem guten Beispiel mit der Suche in Listen herumreiten oder die Vorschläge madig machen (die ja für alle nachvollziehbar wirklich etwas bringen), sondern eher den Blick darauf lenken, das man, bevor man sich eine neue CPU kauft, vielleicht das Geld doch eher in die Lektüre von guten Büchern über Algorithmik- und Datenstrukturen investiert. Das ist mit Sicherheit nachhaltiger.

Oder darin, wie man eine Datenbank richtig aufsetzt, die Indexe richtig setzt und Abfragen performant formuliert.

Ich habe hier Kandidaten, die ihren SQL-Server mit 128 GB RAM ausstatten und sich dann freuen, das ihre Query doch tatsächlich nur noch 10 Sekunden dauert, obwohl das mit 4GB und dem Einrichten eines passenden Index auch in 0.1 Sekunden ginge.

[Stevie]

Zitat:

Zitat von newbe (Beitrag 1272403)

@stevie

naja ich kanns nicht so schreiben??? Wenn ich deinen Post vorhin richtig verstanden habe muss ich
auf das Item über irgendwelche comperator Interfaces drauf zugreifen?

dat hier meinte ich

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.

der Unterschied fällt dir auf? gerade geschachtelte Liste und Array Acessoren finde ich hässlich.

In einer generischen Liste intern kann bei einem IndexOf of nunmal kein = benutzt werden, weil der Typ T alles sein kann, auch Zeugs, wofür der Gleich Operator nicht definiert ist (z.b. Records). Dafür gibt es die comparer, die in der unit Generics.Defaults versteckt sind und die für alle möglichen Datentypen die Vergleiche bereitstellen. Das ist natürlich overhead, erst eine Interface Methode aufzurufen, als direkt einen Vergleich inline zu machen.

Das Argument, das hätte man auch anders lösen können, mit operator constraints oder handoptimierten IndexOf und sonstigen Methoden, lasse ich allerdings zu. Um 2 Integer oder strings zu vergleichen muss ich nicht zwangsläufig nen extra Gerät fragen, dafür gibts das ja schließlich schon zig Jahre in der Sprache selbst. Auf der konsumierenden Seite der generischen Liste, die ja typisiert ist, hat man aber Zugriff auf alles, was der jeweilige Typ kann.

Aber was das nun mit einer for-in/foreach Schleife und Enumeratoren zu tun hat, versteh ich grad nicht. Eventuell fehlt dir aber nur einfach der Überblick über Generics.

Aber dieses ganze Performanceverlust Gelaber ist sowieso mal wieder typische Delphianerkrankheit, wenn ich in einer Liste von 100000 Elementen 10000mal das letzte Element suche und das mit ner linearen Suche mache, dann hab ich entweder Alzheimer oder heiße Schlemiel. ;)

Zitat:

Zitat von Dejan Vu (Beitrag 1272404)

Ich habe hier Kandidaten, die ihren SQL-Server mit 128 GB RAM ausstatten und sich dann freuen, das ihre Query doch tatsächlich nur noch 10 Sekunden dauert, obwohl das mit 4GB und dem Einrichten eines passenden Index auch in 0.1 Sekunden ginge.

Haha, der war gut. Hab ich auch schon erlebt :)

Dennoch bei der ganzen Diskussion ist es trotzdem wichtig, dass die zugrundeliegenden Datenstrukturen optimiert sind, und da ist an der einen oder anderen Stelle sowohl in der RTL als auch im Compiler noch Verbesserungspotenzial :)

[jbg]

Zitat:

Zitat von Stevie (Beitrag 1272408)

wenn ich in einer Liste von 100000 Elementen 10000mal das letzte Element suche und das mit ner linearen Suche mache, dann hab ich entweder Alzheimer oder heiße Schlemiel. ;)

Oder, was traurig ist, heiße Embarcadero. Die IDE strotzt nur so von solchen Listenverwendungen.

[newbe]

Zitat:

Aber dieses ganze Performanceverlust Gelaber ist sowieso mal wieder typische Delphianerkrankheit, wenn ich in einer Liste von 100000 Elementen 10000mal das letzte Element suche und das mit ner linearen Suche mache, dann hab ich entweder Alzheimer oder heiße Schlemiel.

Hast du schonmal ein eigenes ORM geschrieben? Dann weist du wozu du die Listensuche brauchst und warum die nich schnell genug sein kann.

mfg newbe

[Stevie]

Zitat:

Zitat von newbe (Beitrag 1272419)

Hast du schonmal ein eigenes ORM geschrieben? Dann weist du wozu du die Listensuche brauchst und warum die nich schnell genug sein kann.

Jo hab ich, aber normalerweise nutzt man nen ORM nicht um alle Records aus der DB in ne Liste zu laden und wenn dann ist man schön bescheuert (im Sinne von falsches Werkzeug benutzt).
Und wenns um das Auflösen von Assoziationen geht, dann wird man nich xmal dieselben linearen Lookups machen sondern sie über die ID oder sonstwas hashen.

[newbe]

hin oder her ich bin trotzdem der meinung das der neue Code nicht langsamer sein sollte als der alte, schon gar nicht wie in dem bsp. von jbg.