VST - schnelle Suche über 42000 Datensätze

[Piro]

Moin zusammen,

mit diesen beiden Proceduren, filtere ich über ein VST. Die Proceduren stammen aus dem VST Videotutorial vom Stammtisch. Die Daten liegen in einer Klasse TOData.

Delphi-Quellcode:

procedure Tfrm_main.edt_searchChange(Sender: TObject);
begin
 vst_daten.IterateSubtree(nil, SearchDataCallback, nil);
end;

procedure Tfrm_main.SearchDataCallback(Sender: TBaseVirtualTree; Node: PVirtualNode; Data: Pointer; var Abort: Boolean);
var
 Daten : TOData;
begin
 Daten := TOData(vst_daten.GetNodeData(Node)^);
 vst_daten.IsVisible[node] := (edt_search.Text = '')
                                or (pos(LowerCase(edt_search.Text), LowerCase(Daten.suchfeld)) > 0);
end;

Ich lese Daten aus einer Textdatei aus und stelle sie ins VST. Das geht verdammt schnell
Sobald man im Editfeld etwas einträgt, schaut er ins VST und lässt nur noch die Datensätze sichtbar, die dem Suchbegriff entsprechen. Siehe Prozeduren.

Bei einer Datenmenge von ca. 2000 geht die Aktualisierung der VST Ansicht noch recht schnell. Aber bei 42000 Datensätzen ist die Aktualisierung des VSTs sehr langsam und träge und der Benutzer muss auf die weitere Eingabe ins Editfeld warten.

Wie könnte man den Filter optimieren? Welche Möglichkeiten biete das VST?

Eventuelle Alternative (keine Ahnung, ob es geht): Daten in ein DataSet zu laden, und dann mit SQL Befehlen zu filtern.

Danke im Voraus
Sven

[mirage228]

Hey Sven,

Ich würde jetzt vermuten, dass der Aufruf von Pos bei 42.000 Datensätzen etwas länger dauert. Eventuell kannst Du ja dafür hier in der Code-Lib der DP oder in der FastCode-Bibliothek schnelleren Ersatz finden.

Viele Grüße

[Gausi]

Ich hatte so ein Problem auch mal. Ich habe dabei festgestellt, dass nicht die Funktion Pos, also die Mustersuche der Flaschenhals war, sondern der Zugriff auf die zig-tausend Objekte. Die Verwendung einer schnelleren Alternative zu Pos bringt da praktisch nichts.

Ich habe das dann so gelöst, dass ich die Strings von allen Daten in einen String zusammenschreibe, und in einem zusätzlichen Array merke, an welcher Stelle des Super-Strings welches Objekt anfängt. (Benötigt natürlich doppelten Speicherplatz ).
Diesen String durchsuche ich dann, und bei einem Treffer an Position x suche ich binär in dem Index-Array, welches Objekt an dieser Stelle steht. Das wird dann angezeigt, die übrigen nicht.

Die Größenordnungen sahen bei mir in etwa so aus: String-Gesamtgröße: ca. 10mb, 50.000 Objekte. Durchsuchen vor der Optimierung: ~300ms. Duchsuchen mit Pos-Alternative: ~250ms. Suchen mit neuer Methode: <50 ms. Das war dann schnell genug für "Echtzeit-Suche".

[Stevie]

Dafür gibts den var Parameter Abort, damit kannst du den momentanen Suchlauf (der ja hinfällig ist, weil der Benutzer schon nen Buchstaben mehr oder so eingegeben hat) abbrechen. Musst also nur dafür sorgen, dass dieser richtig gesetzt wird.

[jbg]

Zitat von mirage228:

der Aufruf von Pos

Pos dürfte hier weniger das Problem sein. Gravierender ist, dass hinter "edt_search.Text" ein WM_GETTEXT-SendMessage Aufruf an das Edit-Control steckt. Das dauert schon mal lange. Diesen kann man durch einmaliges auslesen und zwischenspeichern vor dem IterateSubtree() Aufruf in den Griff bekommen.
Was aber auch recht lange dauert, sind die beiden LowerCase-Aufrufe. Mit dem zwischengespeicherten edt_search.Text kann man schon mal einen loswerden, indem man bei der Zwischenspeicherung bereits LowerCase ausführt. Um den zweiten LowerCase loszuwerden, müsste man von Pos zu einer Case-Insensitiven Pos-Funktion wechseln (die aber nicht selbst wieder das LowerCase macht, wie so viele Pos-Nachahmungen).

Delphi-Quellcode:

type
  Tfrm_main = class(...)
  private
    FEditText: string;
  end;

procedure Tfrm_main.edt_searchChange(Sender: TObject);
begin
  FEditText := LowerCase(edt_search.Text);
  vst_daten.IterateSubtree(nil, SearchDataCallback, nil);
end;

procedure Tfrm_main.SearchDataCallback(Sender: TBaseVirtualTree; Node: PVirtualNode; Data: Pointer; var Abort: Boolean);
var
 Daten : TOData;
begin
 Daten := TOData(vst_daten.GetNodeData(Node)^);
 vst_daten.IsVisible[node] := (FEditText = '') or (pos(FEditText, LowerCase(Daten.suchfeld)) > 0);
end;

[Stevie]

Hab bei nem Test noch gemerkt, dass du auf jeden Fall vom VST BeginUpdate vor dem Iterate und EndUpdate danach aufrufen solltest.

[Piro]

Wo muss denn das Begin- / EndUpdate rein? In die OnChange Prozedure oder in die anderer Procedure?

@jbg: Danke für den Tip mit dem LowerCase. Der hat schon mal echt ne Menge gebracht und es ist jetzt zu 99% brauchbar.

Danke dir nochmal und alle anderen für die Tipps.

Gruß, Sven

[Piro]

Genial. Mit dem letzten Tipp, läuft es jetzt schnell.

Danke an alle. Mit diesen Infos kann ich jetzt auch noch meine anderen Programme optimieren.

Schönes Wochenende.