![]() |
AW: RTL Performance D7 vs XE7
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. |
AW: RTL Performance D7 vs XE7
Zitat:
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 ![]() Zitat:
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 :) |
AW: RTL Performance D7 vs XE7
Zitat:
|
AW: RTL Performance D7 vs XE7
Zitat:
mfg newbe |
AW: RTL Performance D7 vs XE7
Zitat:
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. |
AW: RTL Performance D7 vs XE7
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.
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 01:47 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz