WPF Performance, wo ist sie hin?

Hallo,

ich habe ein DataGrid in das über einen TemplateSelector verschiedene ContentControls in den DetailView geladen werden und diese wiederum aus verschiedenen ContentControls bestehen. Nun werden außerdem Storybords für das Öffnen und Schließen des DetailViews angestoßen.

Leider lässt nun die Performance bei der Ausführung sehr zu wünschen übrig. Die Eigenschaften vom DataGrid selbst bin ich schon alle durchgegangen (VirtualizingStackPanel.VirtualizationMode="Recycling" / VirtualizingStackPanel.IsVirtualizing="True" usw)

Nun habe ich mir mal das SDK Performance Profiling Tool etwas näher angeschaut und dabei festgestellt dass ein sehr großer Teil der Ressourcen von Dispatcher Invoke verbraucht wird. Das ist, im weitesten Sinne, eine Art Manager der Warteschlange!?

Dazu habe ich nun meine Frage; wie kann ich die Anwendung optimieren um der Methode Dispatcher Invoke "Arbeit" abzunehmen? Spielt die Verschachtelung der Elemente ineinander dabei eine Rolle?

Vielen Dank für Eure Anmerkungen.

Wieviele Elemente zeigst Du denn in Deinem Datagrid an? Ich begrenze die eig. immer so auf 50-100, mehr kann und mag ja eh kein Mensch lesen.

Hast Du mal den Stacktrace überwacht? Performance-Einschränkungen hatte ich bislang weniger wegen der XAML-Elemente, sondern eher "Design-Flaws", sprich ich hatte eher Objekte mehrfach erstellt, da ja in WPF alles ziemlich Event-basiert abläuft. Auf so eine Problematik würde ich da eher tippen, darum.

Aber ist schwierig was dazu zu sagen, ohne den konkreten Code zu kennen. Am besten schau Dir mal Deinen Stacktrace an und versuche das was Du dem Anwender präsentierst auf ein gesundes Mittelmaß zu beschränken, würd ich jetzt mal sagen.

Grüße
m74

Das Problem tritt unabhängig von der Anzahl der Datensätze auf, also auch mit 20 Einträgen sit die Performance nicht wesentlich besser.

großer Teil der Ressourcen von Dispatcher Invoke verbraucht wird. Das ist, im weitesten Sinne, eine Art Manager der Warteschlange!?

Naja - dort wird auch eigener Code ausgeführt.

Profile deine Anwendung mal etwas gründlicher; ich nehme an, dass Problem liegt eher in deinem Code.

Hallo,

wie es der Zufall so will: ca. eine Stunde bevor ich diesen Beitrag gelesen habe, habe ich beim Komplett-Umbau meines Projektes (u.a. Persistierung der Daten von eigener xml-Datei-Struktur hin zu Datenbank mittels NHibernate... aber eigentlich unwichtig) die Performance ca. um den Faktor 6 verbessert... und das zufälligerweise.. juhu 😄

Ich nutze ebenfalls (sehr intensiv) den DataTemplateSelector, welcher u.a. sogar externe Dateien als Resourcen einliest. Die grausame Performance kam dadurch zustande das eigentlich gleiche Objekte mehrfach erzeugt wurden. Da ich jetzt maximal mit gefährlichem Halbwissen glänzen würde, lass ich den Fakt mal im Raum stehen.

Nachdem ich nun gleiche Objekte nach einmaligem Erstellen nur noch zuweise (und nicht mehr jedes mal neu er- und damit vermutlich dar-stelle) ist die Zeit für das Laden des Projektes von ca. 30s auf 5s geschrumpt.... und ich bin mir sehr sicher da ist noch Potential nach unten!

Kann es bei dir evtl. auch daran liegen?

Hallo,

wie realisierst du das "zuweisen" statt dem neu Erstellen was ja der Standard ist?

Danke. Viele Grüße.

Bei WPF muss man auch drauf achten, wie die Anwendung selbst aufgebaut sind.
Ich kann leider nicht mehr genau sagen, welche Schachtelungen unvorteilhaft sind; jedoch wurde auf einem TechNet-Event auf eine saubere und bedachte Schachtelung hingewiesen.

Hallo, vielen Dank für deinen Beitrag.

Was genau ist denn eine "saubere" und / oder "bedachte" Schachtelung? Wodurch zeichnet diese sich aus und welche Konstruktionen erfüllen diesen "Tatbestand" nicht, kannst du dazu etwas sagen?

Vielen Dank.

wie realisierst du das "zuweisen" statt dem neu Erstellen was ja der Standard ist?

Hallo,

also wie gesagt habe ich bisher die Daten (ziemlich redundant) in einer xml-Datei gespeichert. Beim Einlesen habe ich jedes mal neue Objekte erzeugt. Nun schaue ich aber ob die Objekte schon vorhanden sind (bspw. über einen Vergleich der Properties oder eleganter über den Hashcode) und verwende gleichartige Objekte eben nur einmal. So solllten die Daten dann ja auch in der Datenbank landen... Hibernate hat mir die Augen geöffnet 😃

Falls du jetzt immer noch nicht weißt wie ich das mache kann ich dir ja mal beispielhaft zeigen wie mein Importer (von alt auf neu, also lahmarschig auf einigermaßen schnell) funktioniert.