Prestazioni dell'applicazione WPF C#

Question

Abbiamo un'applicazione C# WPF scritta in .Net 4.0, che presenta alcuni semplici collegamenti dati e funzionalità della griglia.

Lo stile elabora alcune "modifiche", inclusi alcuni colori di passaggio del mouse e così via.

Su 3 macchine, al di fuori di una copertura di distribuzione 20, stiamo riscontrando alcuni problemi di prestazioni molto strani con l'interfaccia utente.

In effetti, dopo un riavvio l'applicazione si comporta bene, ma dopo un certo periodo di tempo (non determinato), l'interfaccia utente diventa incredibilmente fiacca. Ad esempio, passando il mouse sopra un pulsante, si verificherà un ritardo di un paio di secondi prima che lo stile del colore al passaggio del mouse venga applicato/reso.

Le macchine hanno specifiche quasi identiche. I driver grafici sono stati aggiornati e l'impostazione starndard è di due schede NVidia Quadro 290. Additivamente, abbiamo creato un'applicazione "test" contenente SOLO alcuni componenti dell'interfaccia utente di test (incluso il nastro Fluent) e nessun codice. Il problema si verifica ancora.

Ho eseguito Windows Performance Suite per "approfondire" il WPF di runtime e, molto stranamente, l'interfaccia utente ritorna alla normale reattività se l'opzione "Disattiva supporto area sporca" è spuntata. La mia comprensione è che, se mai, questo dovrebbe diminuire ulteriormente le prestazioni !!!

Sono a corto di qualsiasi altra cosa da provare qui. Un'analisi delle prestazioni di DotTrace suggerisce che la maggior parte del tempo di applicazione viene speso in PresentationFramework.dll.

[EDIT] Tutte le macchine sono Windows XP SP3.

[EDIT] È possibile che ciò si verifichi su tutte le macchine e che di solito l'applicazione non venga eseguita per un tempo sufficiente a presentare il problema. Lo stiamo testando ora.

[EDIT] Vorrei anche sottolineare che stiamo sperimentando l'aggiornamento rapido dettagliato here. È stato installato su una singola macchina per il momento e aggiornerò di conseguenza.

[EDIT - 24 ore dopo] Quindi due macchine hanno eseguito lo stesso codice durante la notte. Sulla mia macchina (che non ha mai dimostrato il problema), dopo il primo accesso l'applicazione è stata molto lenta, ma dopo meno di un minuto è tornata alla normalità. (L'ho messo giù sulla macchina, eliminando chiaramente l'HDD). Sull'altra macchina (che di solito dimostra il problema), l'applicazione è migliorata dopo pochi secondi, ma è ancora lenta rispetto alla mia.

[EDIT - 48 ore più tardi] Sulla macchina di prova, l'applicazione di test è ora completamente non risponde (bloccato) dopo l'esecuzione per 48 ore. Sulla stessa macchina, un'applicazione WPF 'shell' leggera (contenente un controllo struttura a schede, alcuni pulsanti e alcuni pannelli e griglie) è ancora in esecuzione e perfettamente reattiva. Quindi qualcosa in questi controlli più complessi sta causando questo problema ... che in effetti punta a (potenzialmente) trigger e delegati che potrebbero essere la causa principale. Cercherò di nuovo profilo dell'applicazione/controlli. Nel frattempo qualcuno ha qualche consiglio su come assicurarsi che l'applicazione "ripulisca" se stessa a intervalli regolari? Perché stiamo guardando i controlli di terze parti qui, quindi le mie opzioni per modificarle sono limitate!

Apprezzerebbero eventuali suggerimenti che possono essere forniti!

Answer 1

tenta di rendere wpf in modalità software.

nell'evento caricati:

HwndSource hwndSource = PresentationSource.FromVisual(this) as HwndSource; 
HwndTarget hwndTarget = hwndSource.CompositionTarget; 
hwndTarget.RenderMode = RenderMode.SoftwareOnly; 

Answer 2

Qualcosa da considerare quando si confrontano le prestazioni tra le macchine di sviluppatori e utenti è il tempo necessario per caricare gli assembly WPF.

Su una macchina di sviluppo è possibile che Visual Studio sia già in esecuzione o che in precedenza siano state eseguite altre app WPF e che tutti gli assembly siano stati caricati al momento dell'esecuzione della app.

Su una macchina utente, probabilmente appena riavviata, gli assiemi verranno caricati all'avvio dell'app, rallentando notevolmente l'avvio. A seconda di come è configurata l'app, potrebbero esserci carichi aggiuntivi durante il caricamento di varie funzioni/pagine per la prima volta.

Ho trovato che lo EQUATEC profiler è utile per il debug di questi problemi di prestazioni. Cambiando il profilo in "Informazioni normali complete" nelle opzioni dell'app prima di costruire il tuo progetto, il profilo si ridurrà al livello di binding.