mikrocontroller.net

Forum: PC-Programmierung C# Eigenert TreeView sehr langsam


Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo NG,

ich hätte da mal eine Frage an die C# Profis unter euch.

Ich bin gerade dabei mich in C# (WPF) einzuarbeiten. Ich habe einen 
TreeView geschrieben, der mal grob gesagt so aussieht:

Ein Node selbst ist ein Stackpanel Horizontal, um den Öffner ([+]/[-]) 
und ein NodeIcon und den NodeText anzuzeigen. Darunter liegen ggf. 
weitere ChildrenNodes (auch in einem Stackpanel (vertikal)) um diese 
anzuzeigen (visible) oder nicht anzuzeigen (collapsed). Nachdem das 
alles fertig war habe ich testweise mal einen Node generiert, der 10.000 
Children hat. Die befüllung dauert ungefähr 5 Sek. Das Aufklappen 
(lediglich auf visible schalten) auch nochmal so 5 Sek. Das schmeckt mir 
ehrlich gesagt gar nicht. Mein Ziel wäre es, einen sehr schnellen 
TreeView zu haben, der auch mit max 300.000 Datensätzen schnell zurecht 
kommt. Habt Ihr ´ne Idee, wie man sowas in C# machen kann, oder wird das 
grundsätzlich nicht funktionieren?

PS.: Den vorhandenen TreeView wollte ich eigentlich nicht benützen. 
Primär die Frage, warum das Visible-Schalten des bereits befüllten 
Stackpanels so lange dauert.

Bin schon gespannt auf Eure Ideen.

MfG
Peter

Autor: Hellseher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter schrieb:
> Ich habe einen TreeView geschrieben

Ganz klar, du machst nach jedem Insert einen Bubble sort aller childs in 
Zeile 132.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Naja, ich weiß schon... Ich wollte ja nur mal Fragen, ob das mit der 
Geschwindigkeit nicht schneller geht. Vor allem das Anzeigen, der 
bereits befüllten Stackpanels.
<UserControl x:Class="XXX.DataTreeItem"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" 
             xmlns:d="http://schemas.microsoft.com/expression/blend/2008" 
             mc:Ignorable="d" 
             d:DesignHeight="500" d:DesignWidth="300">
    <Grid SnapsToDevicePixels="True">
        <StackPanel HorizontalAlignment="Left" Name="stackPanel1" VerticalAlignment="Top">
            <StackPanel Name="stackPanel2" Orientation="Horizontal" VerticalAlignment="Top">
                <Image Height="9" Name="nodeOpener" Stretch="Fill" Source="/XXX;component/Images/Tree/empty.png" SnapsToDevicePixels="True" Width="6" Margin="3,0,2,2" MouseUp="nodeOpener_MouseUp" />
                <Image Height="16" Name="nodeIcon" Stretch="Fill" Width="16" Source="/XXX;component/Images/Tree/Icons/folder.PNG" Margin="3,0,3,2" />
                <TextBlock Name="nodeText" Text="BTex_gt" SnapsToDevicePixels="True" Foreground="#FF3B3B3B" Height="16"></TextBlock>
            </StackPanel>
            <StackPanel Margin="11,0,0,0" Name="stackPanel3" Visibility="Collapsed" ManipulationCompleted="stackPanel3_ManipulationCompleted" />
        </StackPanel>
    </Grid>
</UserControl>

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stichwort wäre Virtualized TreeView
Generell ist es, vor allem bei großen Datenmengen, günstiger nicht alle 
UI-Elemente vollständig anzulegen, sondern wiederzuverwenden...
http://msdn.microsoft.com/en-us/library/cc716882.aspx (beim TreeView 
geht dies erst ab .NET 3.5)
http://msdn.microsoft.com/en-us/library/cc716879.aspx (Optimierungstips)

Ansonsten kann man z.B. sowas 
http://www.codeproject.com/KB/tree/VTreeView.aspx machen.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

was mich aber jetzt trotzdem noch verwundert: wenn ich das (bereits 
befüllte) Stackpanel für die ChildrenNodes das erste Mal öffne, dauert 
es sehr lange es anzuzeigen. Wenn ich es dann wieder schließe und danch 
wieder öffne geht alles ganz schnell...

Das man jede Menge optimieren kann, indem man z.B. nur immer die Nodes 
darstellt, die sich an der jeweiligen Scrollbarposition befinden ist mir 
schon klar. Ich verstehe jedoch nicht, warum das Teil "von Haus aus" so 
zäh ist.

In der Arbeit programmiere ich eigentlich vorwiegend mit PHP 
irgendwelche Browser-Anwendungen. Von C# als "lokaler" Anwendung hätte 
ich mir da ein bisschen so eine Art "Kick" erwartet...

@Arc Net: Sind die Techniken in den Links dafür geschaffen, z.B. einen 
Baum mit 300.000 Datensätzen schnell anzuzeigen. Was ich halt nicht 
möchte ist das irgendwas an irgendeiner Stelle sich "zäh" anfühlt... 
gerade der Tree, der einen schnellen Zugriff auf die Daten gewähren 
soll, sollte absolut flott funktionieren.

mfg
Peter

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter schrieb:
> Hallo,
>
> was mich aber jetzt trotzdem noch verwundert: wenn ich das (bereits
> befüllte) Stackpanel für die ChildrenNodes das erste Mal öffne, dauert
> es sehr lange es anzuzeigen. Wenn ich es dann wieder schließe und danch
> wieder öffne geht alles ganz schnell...
>
> Das man jede Menge optimieren kann, indem man z.B. nur immer die Nodes
> darstellt, die sich an der jeweiligen Scrollbarposition befinden ist mir
> schon klar. Ich verstehe jedoch nicht, warum das Teil "von Haus aus" so
> zäh ist.

Sagen wir's mal andersrum: Mir ist auch kein natives UI-Toolkit/Control 
bekannt, welches ohne "Virtualisierung" bei solchen Datenmengen noch 
akzeptabel reagieren würde...
Der Grund ist ganz einfach, dass diese Standard-Controls nicht für 
solche Datenmengen ausgelegt sind. D.h. da wird's immer auf ein eigenes 
Control hinauslaufen, was alles selber macht (Zeichnen, 
Datenverwaltung/Caching etc.)

> In der Arbeit programmiere ich eigentlich vorwiegend mit PHP
> irgendwelche Browser-Anwendungen. Von C# als "lokaler" Anwendung hätte
> ich mir da ein bisschen so eine Art "Kick" erwartet...

s.o.

> @Arc Net: Sind die Techniken in den Links dafür geschaffen, z.B. einen
> Baum mit 300.000 Datensätzen schnell anzuzeigen. Was ich halt nicht
> möchte ist das irgendwas an irgendeiner Stelle sich "zäh" anfühlt...

Probier's aus! Mit 1000 Elementen auf der ersten Ebene und jeweils 1000 
auf der zweiten, läuft's hier akzeptabel.
(Beispiel von oben http://msdn.microsoft.com/en-us/library/cc716882.aspx 
und 10 bzw. 100 durch 1000 ersetzt).

> gerade der Tree, der einen schnellen Zugriff auf die Daten gewähren
> soll, sollte absolut flott funktionieren.

s.o.


>
> mfg
> Peter

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Arc Net,

ich wollte das Beispiel auch eben mal ausprobieren. Leider bekomme ich 
diese beiden Fehlermeldungen beim Compilieren:

Fehler  1  "'src' ist ein nicht deklariertes Präfix. Zeile 8, Position 
18."- XML ist nicht gültig.  C:\Users\Karin\AppData\Local\Temporary 
Projects\WpfApplication1\MainWindow.xaml  8  18  WpfApplication1

Fehler  2  Der src:TreeViewData-Typ wurde nicht gefunden. Alle 
Assemblyverweise müssen vorhanden sein, und alle Assemblys, auf die 
verwiesen wird, müssen erstellt worden sein. 
C:\Users\Karin\AppData\Local\Temporary 
Projects\WpfApplication1\MainWindow.xaml  8  18  WpfApplication1

Hättest Du mir da bitte einen kleinen Tip, was das sein könnte? Ich habe 
in VS C# Express ein neues WPF Projekt angelegt. Im MainWindow.xaml.cs 
habe ich using System.Collections.ObjectModel; und nach dem Namespace 
WpfApplication1 habe ich in einem neuen namespace src den Code für die 
beiden Klassen von der Seite (dein Link) eingefügt. In der xaml Datei 
habe ich den xaml-Code von der Seite zwischen dem Grid eingefügt...

MfG
Peter

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
src ist nur ein Prefix, der deklariert werden muss.
Ist der Namensraum bspw. MyNamespace (in C#) sieht das z.B. so aus
<Window x:Class="MyNamespace.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:src="clr-namespace:MyNamespace"
       ...
>
Soll der Namensraum src bleiben, wäre das in dem Bespiel 
xmlns:src="clr-namespace:src"

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Arc Net,

hab´s dank Deiner Beschreibung hinbekommen :-) Aber ich muss echt sagen, 
dass mir das Ergebnis überhaupt nicht gefällt (MAC mini Core 2 Duo 2GHz 
3GB RAM Win7 ohne OSX)... Hab nur einen Knoten auf Level1 mit 300000 
Unterknoten. Aufklappen dauert so 2 Sek.  Scrollverhalten über die 
300000 Knoten ist absolut inakzeptabel.

Hmm, ich hätte schon viele Ideen, wie man das umsetzen könnte. Aber mal 
was anderes:

Ist das verkehrt, sich am Anfang darüber Gedanken zu machen, wie dieser 
Tree perfekt arbeitet, oder fällt das unter "premature optimization is 
the root of all evil"? Nachdem der Baum M.E. eine zentrale Rolle bei mir 
spielt, wäre mir schon sehr daran gelegen, dass sich alles so verhält, 
wie ich es mit von moderner Software wünschen würde...

MfG
Peter

Autor: __tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter schrieb:
> Ist das verkehrt, sich am Anfang darüber Gedanken zu machen, wie dieser
> Tree perfekt arbeitet, oder fällt das unter "premature optimization is
> the root of all evil"? Nachdem der Baum M.E. eine zentrale Rolle bei mir
> spielt, wäre mir schon sehr daran gelegen, dass sich alles so verhält,
> wie ich es mit von moderner Software wünschen würde...

mit WPF gehts nur mit "virtualisierten" wiederverwendeten elementen (das 
erzeugen von visuals ist gelinde gesagt: etwas träge), von daher ists 
nicht verkehrt sich vorher darüber gedanken zu machen. der "premature 
optimization" spruch bezieht sich darauf das man vorher den code 
funktionierend hat und danach die letzten millisekunden rauskitzelt.

Autor: Sam .. (sam1994)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde den Treeview schon nehmen. Man muss halt ein bisschen 
tricksen, aber dann geht das auch.

Man kann ein Treeview irgendwie virtual laufen lassen. Dabei musst du 
sobald man scrollt die Datensätze nachladen. Bzw. du lädst sie in ein 
Array das als Cache fungiert, wenn nichts gemacht wird. Ich hab das mal 
ohne Cache gemacht. Die Geschwindigkeit passt dann wieder. Allerdings 
hab ich Probleme bekommen als ich die einzelnen Elementen sortieren 
wollte (und zwar nach versch. Vorgaben). Das Treeview Sort kann man ja 
sowieso bei >100k Elementen vergessen und meine Eigene konnte ich auch 
nur auf ca. 1-2 Sekunden optimieren (da muss man eigentlich vorsortieren 
dann klappt das auch).

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.