RTL Performance D7 vs XE7

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

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 von Dejan Vu:

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 von Stevie:

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 von newbe:

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.