WPF lento per l'avvio su x64 in .NET Framework 4.0

Question

Ho notato che se costruisco la mia applicazione WPF per Any CPU/x64, ci vuole MOLTO più tempo per iniziare (nell'ordine di circa 20 secondi) o per caricare nuovo controlla di quanto non faccia se avviato su x86 (nelle modalità di debug &, all'interno o all'esterno di VS). Ciò si verifica anche con le app WPF più semplici. Il problema è discusso in this MSDN thread, ma non è stata fornita alcuna risposta. Questo accade solo con .NET 4.0 - in 3.5 SP1, x64 era veloce come x86. È interessante notare che Microsoft sembra conoscere questo problema poiché l'impostazione predefinita per un nuovo progetto WPF in VS2010 è x86.

Si tratta di un errore o sto semplicemente sbagliando?

MODIFICA: Possibilmente correlato a questo: Slow Databinding setup time in C# .NET 4.0. Sto usando il binding di dati pesantemente.

Answer 1

In realtà ci sono 2 ragioni principali per cui il tipo di progetto predefinito per le applicazioni WPF è x86.

• Intellitrace debug funziona solo con x86 e che apparirebbe piuttosto male se i modelli di progetto di default non ha funzionato con una delle loro caratteristiche stella.
• Molti sviluppatori non erano ancora a conoscenza del fatto che i loro exe AnyCPU sarebbero eseguiti come x64 su macchine a 64 bit e furono sorpresi di scoprire che le DLL a 32 bit su cui si basavano non esistevano in varietà a 64 bit come i driver OLEDB, alcuni nativi DLL, ecc.

Per quanto riguarda i problemi del tempo di avvio che si verificano, sembra quasi un problema con NGEN. Poiché ci sono diverse cache NGEN per i processi x64 e x86, potrebbe essere che la cache NGEN a 64 bit debba essere ricostruita o aggiornata. Provare a eseguire il seguente da un prompt dei comandi con privilegi elevati:

CD C:\Windows\Microsoft.NET\Framework64\v4.0.30319 
NGEN update 

Questo è il comando di ricostruire immagini native per gli assembly che sono già stati contrassegnati per NGEN. Probabilmente, inoltre, non ti sarà di alcuna utilità per l'applicazione NGEN se gli assembly non si trovano anche nel GAC, quindi non mi preoccuperei di provare a farlo. Ma gli assembly framework, i gruppi di toolkit, ecc. Dovrebbero essere tutti NGEN'd.

(A proposito, ho avuto diversi errori quando ho eseguito il comando precedente sugli assembly che non poteva essere caricato. E 'stato in gran parte di SQL e le assemblee di Visual Studio.)