TreeView-Nodes anhand Pfad-String finden (zu langsam)

[Satty67]

Du nutzt ja die Fähigkeiten von SQL, um Dir erst eine Liste zu erstellen, mit der Du dann optimiert arbeiten kannst (richtig?) Die Daten hier liegen aber auf einem alten Werkstatt-Rechner, der kein SQL hat. (Daten-Header werden per TFileStream seriell eingelesen, Tree angelegt und RecNo im Node für späteren Detailzugriff gespeichert).

Bin auch etwas überfordert, mir die ganze Funktion ohne SQL vorzustellen. Weis also im Moment nicht, wie ich die Hilfslisten ohne SQL erzeugen könnte ohne dadurch den Zeitvorteil wieder zu verlieren. Mein Versuch mit String/Object Liste für jeden Node war evtl. so ein Ansatz... da ich aber gleich eine universelle Funktion wollte, hab ich jede Vorbereitung der Daten verworfen.

Das ganze ist auch nur als Zwischenlösung gedacht, um die Daten bei mir in Delphi zur Verfügung zu haben. Später wird das nach SQL konvertiert, aber das dauert noch etwas.

€: Ist ja schon Freitag... werde mich am WE man mit 'ner Kanne Kaffee dransetzen um die Funktionsweise ganz genau zu verstehen und prüfen, wie das ohne SQL umzusetzen ist.

@Chemiker
werde ich heute Mittag schnell probieren und berichten. (das Projekt liegt auf dem Home-PC)

[RWarnecke]

Zitat von Satty67:

Du nutzt ja die Fähigkeiten von SQL, um Dir erst eine Liste zu erstellen, mit der Du dann optimiert arbeiten kannst (richtig?) Die Daten hier liegen aber auf einem alten Werkstatt-Rechner, der kein SQL hat. (Daten-Header werden per TFileStream seriell eingelesen, Tree angelegt und RecNo im Node für späteren Detailzugriff gespeichert).

Ja, dass ist richtig. Mit dem Select-Befehl erzeuge ich mir eine gesamte Tabelle aus der Kategorie und den Einträgen in den Kategorien.

Zitat von Satty67:

Das ganze ist auch nur als Zwischenlösung gedacht, um die Daten bei mir in Delphi zur Verfügung zu haben. Später wird das nach SQL konvertiert, aber das dauert noch etwas.

Warum dieser umständliche Weg ? Ich würde versuchen die Daten auszulesen und gleich in eine Datenbank zu schreiben und dann danach den TreeView aufzubauen.

[himitsu]

Zitat von Satty67:

Du nutzt ja die Fähigkeiten von SQL, um Dir erst eine Liste zu erstellen, mit der Du dann optimiert arbeiten kannst (richtig?) Die Daten hier liegen aber auf einem alten Werkstatt-Rechner, der kein SQL hat. (Daten-Header werden per TFileStream seriell eingelesen, Tree angelegt und RecNo im Node für späteren Detailzugriff gespeichert).

werde die Daten in den RAM geladen und bleiben dan da? (z.B. in Recotrd oder Klassen)

dann lönntest du diese Records auch direkt an den jeweiligen TreeNode anhängen.

Zitat von Chemiker:

vielleicht bringt es noch was den Text-Vergleich mit CompareText durchzuführen.

eigentlich dürfte das langsamer sein, als der direkte Stringvergleich, da CompareText erstmal den beide Strings ändert (Groß-/Kleinschreibung) und erst danach vergleicht.
(bringt nur den Vorteil, daß es CaseInsensitiv vergleicht)

[Satty67]

Zitat von himitsu:

werde die Daten in den RAM geladen und bleiben dan da? (z.B. in Recotrd oder Klassen)
dann lönntest du diese Records auch direkt an den jeweiligen TreeNode anhängen.

Meine allerste Version hat die komplette Datenbank in den Speicher gelesen, Index sortiert und danach "on the fly" in den TreeView eingebaut. Das war fix und unschlagbar schnell, da suchen nach Nodes komplett entfallen ist (Child kam immer nach Parent). Für das aktuelle Programm könnte ich auch bei der Lösung bleiben (auch wenn der Werkstattrechner mit Speicher etwas mager ausgestattet ist). Mein Anliegen war ja jetzt eine möglichst universelle Version, also Optimierung für den Einzelfall bitte abhaken

Es geht also schon in erster Linie darum, eine Funktion zu haben, die nur TTreeView und einen PfadString bekommt und alleine damit arbeiten muss. Die Pfadstrings sollen dabei auch in unsortierter Reihenfolge ankommen dürfen.

Wenn ich jetzt also bedenke, das ein lineares anlegen der 24.000 Nodes ~3500ms dauert, das wahllose anlegen mit String-Vergleich 9500ms (himitsus letzter Vorschag), dann könnte es gut sein, das wir nahe am Optimum sind. Immerhin sind wir von über 31.000ms auf 9.500ms runtergekommen.

***

Was eine spätere SQL-version angeht... wenn ich die Datenbank nach Pfad sortieren lasse, dann muss ich überhaupt keinen Node suchen. Es kommt in der Pfadliste immer Parent vor Child bzw. neuer Parent-Zweig. Ich muss also nur prüfen, ob der letzte Pfad zum nächsten Pfad passt.

[Hybrid666]

bau dir doch erstmal einen baum auf, aus diesem baum machst du dann den treeview. wäre jetzt eine überlegung von mir.

also baum sieht dann aus:

Wurzelverzeichniss
| |
untervrz. untervrz.
| | | |
uuvz uuvz uuvz uuvz

da kannst du sehr schnell suchen und einfügen, wenn du dann alle daten beieinander hast kannst du den treeview aufbauen. geht mittels dem baum auch recht flott dann...


Andere Idee:

In einer Liste Referenzen zu den Nodes speichern, dann anstatt in der TreeView zu suchen in der liste suchen und dann direkt einfügen.

Sieht dann so aus:
/ -> TTreeNode;
/asd -> TTreeNode;
/bla -> TTreeNode;
/asd/möp -> TTreeNode;

wenn du nun /asd/möp/blubb einfügen möchtest, suchst du in der liste nach /asd/möp und speicherst blubb als kind knoten, dannach fügst du es der liste hinzu, damit
/asd/möp/blubb -> TTreeNode; auch drinsteht.

mfG

P.S.: Bitte nicht hauen wenn Idee kagga

mfG

[Satty67]

Also hab' heute noch was gefunden, was den Aufbau doppelt so schnell ausführt. (da hatte ich gepennt)

Zwar sind viele Einträge durcheinander, aber doch nicht alle. Ich prüfe vorm Aufruf von "FindNodeByPath" jetzt, ob AktuellerPad=LetzterPfad und nehme dann den zuletzt gefundenen Node. (Quasi eine 1-Wert-Referenzliste)

Könnte man auch innerhalb der Funktion implementieren, aber wegen der 3 nötigen globalen Variablen (LastTreeView, LastNode und LastPath) lasse ich es im Aufrufer. Sind jetzt 4,5 Sekunden für 24.000 Nodes, mir reicht das und ich kümmer mich jetzt lieber um den restlichen Code.

Die erste Variante von mir läge dann bei ca 15 Sekunden, womit weiterhin >60% mehr Geschwindigkeit durch Eure Mithilfe rausgesprungen sind!

Danke!