Perché lo sviluppo dell'UWP 10 è così lento?

Question

Qualcun altro ha problemi con un'esperienza di sviluppo molto lenta in VS 2015 che scrive app per Universal Windows Platform 10? Compilare, eseguire il debug e persino passare da una finestra all'altra è dolorosamente lento rispetto a lavorare con un'applicazione WPF di base simile.

Non sono stato in grado di trovare alcuna menzione di questa esperienza su Google, il che mi porta a chiedermi se c'è qualcosa nella mia configurazione che sta lanciando una chiave inglese nello sviluppo UWP.

Qualcuno ha provato questo, o conosce qualche modo per accelerare lo sviluppo?

Aggiornamento

Il contesto di questa domanda è la compilazione in modalità debug, non rilascia la modalità (.NET nativo).

Answer 1

Aggiornamento ott 2016

Questa risposta non è più rilevante, come di Visual Studio 2015 Update 3. Microsoft ha svolto un ottimo lavoro riportando l'ambiente di sviluppo a uno stato stabile. Sebbene attualmente abbia problemi con il designer XAML, la codifica dello & è molto più veloce e piacevole. Spero che la maggior parte dei problemi debilitanti riscontrati nel progettista XAML siano risolti nel prossimo Visual Studio 15.

---

Qualcuno ha sperimentato questo

Sì.

Tutti i membri della mia squadra stanno perdendo i capelli a causa dell'UWP. Sono quasi convinto che Microsoft voglia che odio C# & XAML.

... o sapere di tutti i modi per accelerare lo sviluppo?

Sto trasferendo la mia app a UWP ma non posso terminare il supporto per Win8. Quindi, ho entrambi i progetti nella stessa soluzione. Per me, per velocizzare le cose, ho modificato le configurazioni di build in "Debug-UWP" e "Release-UWP" per escludere l'applicazione Win8 ei progetti quando lavoro con l'app di Windows 10. Questo è solo un sollievo minore. Costruire è ancora un'esperienza dolorosa.

anche

è possibile disattivare NuGet di ripristinare pacchetti su ogni generazione. Vai a Opzioni>Gestore pacchetti NuGet e deseleziona "Verifica automaticamente i pacchetti mancanti durante la compilazione in Visual Studio." Anche questo è minore, ma ogni piccolo aiuto.

Answer 2

Solo i miei 2 centesimi, ma di recente ho scoperto che c'è un grosso problema quando si lavora al progetto UWP.

Stavo lavorando al mio progetto con Xamarin per avere un'app compatibile su Android/iOS/WP8 e UWP.

Ma lavorando di recente in Visual Studio 2015 Update 2 (con W10), ho avuto prestazioni molto lente, un'interfaccia molto lenta, Build, Debug, XAML, tutto molto lento.

Quindi ho appena scoperto qualcosa di molto terribile: se si imposta il progetto UWP come progetto iniziale della soluzione, Visual Studio 2015 diventa lento come l'inferno! Non so qual è il vero problema ma questo è stato un vero problema per me!

Ho impostato il mio progetto di avvio su un altro progetto nella soluzione, diverso da UWP e WP8. Se ho bisogno di eseguire il debug, li avvio utilizzando il tasto destro del mouse in Solution Explorer, quindi Debug.

Da allora, VS2015 non ha alcun problema di prestazioni per me.

Answer 3

Affascinante ... semplicemente affascinante.

Disattiva "Compila con .NET Native tool chain" nelle proprietà Build dell'app principale UWP. Le librerie UWP non sembrano offrire l'opzione della catena degli strumenti nativa.

Stavo combattendo il problema del perché la mia applicazione di analisi dei file impiegava circa il doppio del tempo per eseguire (non creare) come build di rilascio che come build di debug. Completamente il contrario di quello che sarebbe dovuto succedere. Mi è anche capitato di notare il lungo tempo necessario per completare la build di rilascio, ma per il momento era un problema secondario.

Se si guarda la finestra di output durante una ricostruzione completa, si noterà che tutte le librerie che si avranno verranno create nel modo più rapido. Quindi l'app principale sarà quella che si impantana: MOLTO.

Controllare le proprietà di creazione per i progetti e si noti che solo l'app UWP principale ha l'opzione "Compila con catena di strumenti nativi .NET". Le librerie non ce l'hanno. Inoltre, per impostazione predefinita solo la versione di rilascio è abilitata. La build di debug no. Abbastanza sicuro, spegnilo nella build di rilascio e la build di rilascio inizia a completare alla stessa velocità della build di debug.

Quindi la stranezza della stranezza ... il mio build di rilascio dell'app UWP ora funziona circa del 10% più velocemente rispetto alla versione di debug quando veniva eseguito quasi due volte più lentamente.

Questo è tutto MOLTO contro-intuitivo. Una build nativa dovrebbe essere veloce, se non addirittura un po 'più veloce, rispetto alla build non nativa. Il compilatore in Visual Studio ha certamente l'opzione di mettere molto più duro lavoro per ottimizzare la build per il processore.

Mi chiedo se non è stato pubblicato altro sui problemi con gli strumenti di creazione nativi e se c'è una spiegazione. Il tempo di costruzione lento posso capire completamente se gli strumenti di costruzione stanno sgranocchiando molto più duramente cercando di ottimizzare per il processore nativo specifico. Tuttavia il fatto che il codice nativo funzioni molto più lentamente del codice non nativo è completamente contro-intuitivo. Non sembra logico che MSFT si sia preso la briga di rilasciare gli strumenti di compilazione nativi in ​​tali circostanze, il che porta a chiedersi se gli strumenti sono stati usati in modo errato o se qualche altro malinteso è avvenuto.