![]() |
Performance von FindComponent
Hallo Leute,
ich habe heute mal eine allgemeinere Frage. Ich generiere die benötigten Komponenten meiner DB-Anwendung dynamisch aus den Inhalten der DB. Beim Start wird für jede Tabelle der DB eine Query-,Dataset- und Datasourcekomponente erzeugt. Diese sind Child-Objekte des Datenmoduls 'DM_Datenbank'. Meine Frage: Wenn ich eine der Komponenten benötige, verwende ich den Aufruf 'DM_Datenbank.FindComponent(MeineKomponente)'. Wie Performant ist dieser Aufruf? Ist dies die beste Lösung die Komponenten zu finden? Oder: Ist es vielleicht besser die Komponenten beim Erzeugen in einem dyn. Array zu speichern(Dann müsste man den Index der benötigten Komponente ermitteln, um diese zu erhalten)? |
Re: Performance von FindComponent
hallo barnti,
berechtigte Frage, ich schätze aber FindComponent ziemlich schnell ein (wenn es nicht verkorkst implementiert ist). Dürfte ja nichts anderes sein als eine Schleife von 0 bis ComponentCount-1 über Components. Sowas darf eigentlich nicht nennenswerte Laufzeit haben. Roderich |
Re: Performance von FindComponent
Zitat:
Greetz alcaeus |
Re: Performance von FindComponent
Hallo,
habe ich mir auch gedacht. Allerdings könnte es sein, dass je nach Cast-Operator (TmysqlQuery(Dm_Datenbank.FindComponent)) das ganze noch optimiert wird. Vielleicht ist dann FindComponent etwas schneller...?! |
Re: Performance von FindComponent
Warum verwendet jeder FindComponent????
Du hast doch schon einen Array of TComponent -> TCustomForm.Components[] !!! Ein simples:
Delphi-Quellcode:
Über die ID kannst du jetzt immer auf deine Komponente zugreifen.
XYZ := TABC.Create(Self);
fXYZ_cID := XYZ.ComponentID; FindComponent MUSS durch den Array iterieren, um die Komponente nach Namen zu finden. Hast du die ID sparst du dir das Ganze.(außerdem sieht der Code sonst irgendwie Newbie-like aus. :roll: ) Zitat:
p.s.: FindComponent ist auch nicht sooo langsam. Schließlich ist es mit Sicherheit nur eine simple Iteration durch den Array Components á la:
Delphi-Quellcode:
for i := 0 to pred(ComponentCount) do
if Components[i].Name = lSearchName then begin result := Components[i]; break; end; |
Re: Performance von FindComponent
Der Cast-Operator bedeuted für den Rechner den wenigsten aufwandt da der Compiler nur diese Interne Zahl anders interpretiert.
FindComponent ist das langsamste was ich kenne, dies merkt man wenn es in größeren Schleifen benutzt wird. Grund: Eine Schleife über alle Elemente. (20 Steuerelmente + sage wird 20 mal suchen sind 400 Stringvergleiche) Ein String vergleich ist, da ein Rechner nur zahlen versteht, ebenfalls eine Schleife. (ca 15 Zeichen pro Name sind 6000 cmp). Cmp ist der Maschinen-Befehl zum vergleichen zweier Zahlen, welches durch eine Subtraktion gemacht wird. Addiert man die Taktzyklen der andere langwierigen Stack-Operationen, Call, Jmp-Befehler, wird man schon auf ein paar ms kommen. Und stellen wir gegenüber eine direkte Adressierung, über eine Variable, die meinetwegen vorher mittels FindComponent gesetzt wurde. Wird man erschrecken. Ein Maschinen-Befehl (ergo 20)! Oben sind es schätzungsweise 10000 (nicht nachgrechnet). |
Re: Performance von FindComponent
Zitat:
Ich dachte schon ich hätte was verpasst. :lol: Ich habe schon eine Allergie gegen solchen ItemByName-Käse seit ich vor 1,5 Jahren mit Delphi angefangen habe. ;) |
DP-Maintenance
Dieses Thema wurde von "Daniel" von "Datenbanken" nach "VCL-Komponenten und Controls" verschoben.
Scheint mir doch eher zu den VCL-Fragen zu gehören. |
Re: Performance von FindComponent
Vorallem findet so der Compiler keine fehlzugriffe!
Bsp: Eine Componente Names txtTest wird in txtText umbenannt. Der Compiler-meckert kein bißchen wenn man mittels FindComponent darauf zugreift! |
Re: Performance von FindComponent
Zitat:
Habe ich die ID allein nützt mit das noch nichts. Oder? Ich lasse mich gern aufklären. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 07:12 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-2025 by Thomas Breitkreuz