Risolvere il problema di prestazioni con l'applicazione WPF

Question

Ho creato un elenco di tutto ciò che può aiutare a migliorare le prestazioni in un'applicazione molto complessa con molti controlli. Se vuoi aggiungere il tuo, il tuo benvenuto!

• Se si conosce la dimensione del controllo, rimuovere l'Auto e immettere il valore reale, in modo che il genitore non deve analizzare tutte le Childs per verificare le dimensioni di cui ha bisogno
• impostare il parametro IsHitTestVisible = False se l'elemento non ha bisogno di essere interattivo
• congelare tutti oggetto che si può
• utilizzare le risorse statico invece di risorse dinamici
• non utilizzare l'oggetto Ellipse, trasformare l'ellisse in un tracciato
• Don usare TextBox o etichetta se è possibile utilizzare un TextBlock
• Usa tela invece di griglia quando possibile
• No FlowDocument
• Virtualizzazione !! VirtualizingStackPanel invece di StackPanel
• Non usare List, l'ObservableCollection è modo più veloce
• utilizzare la libreria di disegno, è più veloce allora la libreria Forme
• Controlla la tua vincolante! Se un legame non funziona, può essere molto lento
• Non utilizzare Visibility.Hidden, utilizzare Visibility.Collapsed quando è possibile
• DependencyProperty è 3 volte più veloce poi INotifyPropertyChanged
• StreamGeometry è più veloce quindi PathGeometry
• Cancella i gestori di eventi quando hai finito con loro!
• Non utilizzare la proprietà dell'oggetto Opacità, se è possibile, utilizzare il suo colore opacità
• Verificare se l'applicazione è resa Hardware (Tier-2)
• Riduci dimensioni/qualità dell'immagine quando è possibile
• L'immagine di rendering è molto più veloce del rendering vettoriale!

strumenti che uso:

• WPF ispettore
• Snoop
• privato WPFPerf
• Visual Studio profiler
• CLR Profiler per .NET

Answer 1

Questo è davvero un commento e non un rispondi ma non abbastanza spazio in commment.

La modalità ObservableCollection più veloce di List mi sembrava controintuitiva come ObservableCollection implementa iList.

Ho una lista di 660.000 parole che ho testato su un ListView (virtualizzazione). Creati i tipi di raccolta di seguito e creato i pulsanti per cambiare l'associazione nel codice dietro. Tutte le collezioni visualizzate istantaneamente (il potere della virtualizzazione).

La variabile è il momento di creare la raccolta e le funzionalità necessarie dalla raccolta. Utilizzato SQLdataReader per popolare la raccolta. Esiste una variabilità in SQLdataReader. Ogni 10 risultati ottenuti ha ottenuto risultati ripetibili a 2 cifre significative e ho riportato la media di 3 cifre significative. List beat ObservableCollection di circa 400 millisecondi. Non ho misurato la memoria ma List chiaramente userà meno memoria.

Millisecondi per caricare 660.000 stringhe con una media di circa 40 caratteri ciascuna.

1510 List 
    1780 Dictionary 
    1820 HashSet 
    1980 ObservableCollection 
    8000 SortedDictionary 

In una raccolta molto grande, HashSet sarebbe migliore di List. HashSet dovrebbe battere Dizionario - quei numeri sono all'interno della variabilità di questo test limitato non rigoroso.

Si tratta di funzionalità. ObservableCollection supporta l'inserimento e l'eliminazione dinamici. Se hai bisogno di inserire e cancellare dinamicamente, è di gran lunga la scelta migliore. Se non hai bisogno di inserire e cancellare dinamicamente la mia esperienza è che List è una scelta migliore (tramite iNotifyPropertyChanged dell'elenco ListItem supporta la revisione dinamica).

Elenco conserva l'ordine in cui vengono aggiunti gli articoli. HashSet non mantiene l'ordine. Molti fattori nella scelta della raccolta da utilizzare. http://geekswithblogs.net/BlackRabbitCoder/archive/2011/06/16/c.net-fundamentals-choosing-the-right-collection-class.aspx

Aveva un commento sul tempo di accesso a un singolo articolo. Ho avuto accesso agli elementi [1], [100000], [200000], [300000], [400000], [500000], [600000] usando List, ObservableCollection e Dictionary. Erano tutti 12 ms. Il tempo di accesso era un calore morto e ripetibile.