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.