[QUOTE=Perlsau;1268418]Mit deiner Methode, das Icon in NodeData zu speichern, verursachst du unnötige CPU-Last beim Handling mit dem VTV, was natürlich bedeutet, daß der Aufbau eines riesigen Trees wie in deinem Fall unnötig verzögert wird. So müssen z.B. die Bitmaps in NodeData beim Umsortieren ständig mitkopiert werden,...[QUOTE] Der Speicherverbrauch wächst minimal, d.h. um 4 Byte pro Record. Deine Argumention ist daher nicht schlüssig. Einzig die eventuell redundante Instantiierung von identischen Icons könnte man verbessern. Hier würde ich einen einfachen Cache vorschlagen. Zu klären wäre nur eine Funktion, die zu einem Icon einen eindeutigen Schlüssel generiert.
Zitat:
Den VTV baust du in einer privaten Methode auf, die z.B. bei Programmstart aufgerufen wird. Dort gehst du deine
DB-Tabelle durch und liest die entsprechenden Spalten aus.
Das verzögert den Programmstart unnötig. Wenn nämlich nicht alle Icons benötigt werden, d.h. vielleicht auch nicht sichtbar sind. Ein Cache macht prinzipiell das Gleiche, nur eben
on demand, bzw. per
lazy load.
Diese Implementierung ist somit skalierbar, d.h. sie funktioniert auch bei sehr großen Datenmengen. Hier wäre natürlich die Visualisierung anzupassen, d.h. nur die Daten zu laden und im Speicher zu halten, die gerade benötigt werden.