Performancefrage für ein einfaches Matching

[fisipjm]

Okay,
zunächst mal Sorry für den geringen Informationsgehalt. Ich versuch mal ein bischen Licht ins dunkel zu bringen.

Die Funktion welche ich aktuell versuche zu optimieren gibt es eigentlich schon. Wir setzen eine Komponente in Delphi ein um auf einen Applikationsserver eines Drittherstellers zuzugreifen, der wiederrum auf eine MSSQL geht.
Dort gibt es eine Funktion zum Feldwerte lesen. Der Aufruf funktioniert grob so:

Delphi-Quellcode:

ThirdPartyComponent.Select('Select Feldname From Tabelle');
ThirdPartyComponent.GetFieldvalue('Feldname');

Ich hab jetzt durch Zufall herausgefunden, dass der Aufruf des Herstellers sich einen Fuß ins Ohr schafft. zu dem Zeitpunkt wo ich den Feldwert aufrufen kann, liegt mir nämlich eigentlich schon das gesamte Ergebnis der ganzen Abfrage als 2 Dimensionales OleVariant Array vor. Beim Aufruf der GetFieldvalue Funktion wird der Wert nochmal auf der Applikationsschicht abgefragt, allerdings nicht in der DB sondern nur in einem internen Cache. Also auch kein Vorteil zum Thema Datenaktualität.

Das Olevariant Array muss ich nun eben mit Olevariant[Spaltennummer,Zeilennummer] aufrufen.

Aufrufzeit für einen Feldwert mit 4181 Zeilen = 4310ms (Komponentenfunktion)
Aufrufzeit für einen Feldwert mit 4181 Zeilen = 1ms (eigene Funktion)

soweit ja schon mal subi Werfe ich jetzt in die SQL Abfrage noch ein 2. Feld rein dann wird aus der 1ms schon 50ms usw.
Das liegt halt daran, dass ich die Komponente gerne kapseln will um nicht den Index aufrufen zu müssen, sondern weiter den Feldwert benutzen kann. Welchen Index der Feldwert hat schreib ich mir also einmalig beim ersten aufruf in das Dictionary und kann dann später in meiner funktion mit der gleichen Sytax den Feldwert wieder mit Namen aufrufen. Das Suchen scheint aber eben mit jedem Eintrag im Dictionary entsprechend länger zu dauern. Das wollte ich gerne ein bisschen einbremsen

Ich hoffe damit wird klarer was ich versuche zu erreichen.

[freimatz]

Klarer ja, klar genug zweifelhaft.
Ich bin mir aber sicher dass für den Geschwindigkeitsnachteil das SQL schuld ist und nicht das TDictionary.

[fisipjm]

Zitat von freimatz:

Klarer ja, klar genug zweifelhaft.
Ich bin mir aber sicher dass für den Geschwindigkeitsnachteil das SQL schuld ist und nicht das TDictionary.

Nö, der SQL Server ist nicht Teil der Geschwindigkeitsmessung. Die beginnt erst nachdem die Daten schon abgeholt wurden.
Welche infos fehlen noch um an ein klar genug ran zu kommen?

[Stevie]

Liest sich ähnlich zu der FieldByName Problematik, wenn man das in einer Schleife immer benutzt anstatt vor der Schleife einmal die Felder über FieldByName zu holen, um dann darauf zuzugreifen.

Wie macht man Dinge schneller? Man vermeidet redundante Arbeit - in diesem Fall das ermitteln des Indexes per Name indem man es einmal vor der Schleife macht.

[Uwe Raabe]

Zitat von Stevie:

Liest sich ähnlich zu der FieldByName Problematik, wenn man das in einer Schleife immer benutzt anstatt vor der Schleife einmal die Felder über FieldByName zu holen, um dann darauf zuzugreifen.

Das ist aber mittlerweile auch nicht mehr ganz so problematisch wie früher, seitdem das über ein Dictionary realisiert wird.

Delphi-Quellcode:

function TFields.FindField(const FieldName: string): TField;
begin
  FDict.TryGetValue(AnsiLowerCase(FieldName), Result);
end;

[himitsu]

Zum Glück setzt dieses TDictionary<K,V> das Value auch dann, wenn nichts gefunden wurde, sonst wäre das Result von FindField nicht initialisiert, weil niemand das Result vom TryGetValue auswertet.

[Stevie]

Zitat von Uwe Raabe:

Das ist aber mittlerweile auch nicht mehr ganz so problematisch wie früher, seitdem das über ein Dictionary realisiert wird.

Sind aber trotzdem bei 4181 Zeilen mit 2 Feldern 8360 unnütze Aufrufe. Die Quintessenz des Threads hier war bisher die Frage "wie bekomm ich das matching schneller" und ich hab einfach in den Raum gestellt "mach es nicht schneller, sondern lass es weg".

P.S. Bei dem AnsiLowerCase anstatt eines case insensitiven EqualityComparers (und ich mein nicht den aus System.Generics.Defaults, der ist nämlich auch Schrott, da er nix anderes als AnsiLowerCase macht) dreht sich mir übrigens der Magen um.

[freimatz]

Zitat von fisipjm:

Zitat von freimatz:

Klarer ja, klar genug zweifelhaft.
Ich bin mir aber sicher dass für den Geschwindigkeitsnachteil das SQL schuld ist und nicht das TDictionary.

Nö, der SQL Server ist nicht Teil der Geschwindigkeitsmessung. Die beginnt erst nachdem die Daten schon abgeholt wurden.
Welche infos fehlen noch um an ein klar genug ran zu kommen?

Deine Aussage "Werfe ich jetzt in die SQL Abfrage noch ein 2. Feld rein dann wird aus der 1ms schon 50ms usw." lies mich zum Schluß kommen dass da was mit SQL dabei ist.
Wie die Kollegen hier auf FieldByName kommen erschließt sich mir nicht. Wenn denen das klar ist reicht das ja. Kompetentere wie z.B. Uwe und Stevie lassen sich eh nicht finden.

[fisipjm]

Zitat von freimatz:

Zitat von fisipjm:

Zitat von freimatz:

Klarer ja, klar genug zweifelhaft.
Ich bin mir aber sicher dass für den Geschwindigkeitsnachteil das SQL schuld ist und nicht das TDictionary.

Nö, der SQL Server ist nicht Teil der Geschwindigkeitsmessung. Die beginnt erst nachdem die Daten schon abgeholt wurden.
Welche infos fehlen noch um an ein klar genug ran zu kommen?

Deine Aussage "Werfe ich jetzt in die SQL Abfrage noch ein 2. Feld rein dann wird aus der 1ms schon 50ms usw." lies mich zum Schluß kommen dass da was mit SQL dabei ist.
Wie die Kollegen hier auf FieldByName kommen erschließt sich mir nicht. Wenn denen das klar ist reicht das ja. Kompetentere wie z.B. Uwe und Stevie lassen sich eh nicht finden.

Ja, dass stimmt wohl Die CodeRage Beiträge gestern waren wieder erste Sahne
Ihr habt das Problem schon recht gut erkannt. Den Index Weg lassen ist natürlich am schnellsten, aber geht halt auf die "Bequemlichkeit".