Почему разработка UWP 10 настолько медленная?

Ответ 1

Обновление Oct 2016

Этот ответ больше не имеет отношения к Visual Studio 2015 Update 3. Microsoft сделала отличную работу, возвращая среду разработки в стабильное состояние. Хотя у меня в настоящее время проблемы с дизайнером XAML, кодирование и построение намного быстрее и приятнее. Я надеюсь, что большинство изнурительных проблем, обнаруженных в дизайне XAML, будут разрешены в следующем Visual Studio 15.

Кто-нибудь испытал это

Да.

Каждый из моей команды теряет волосы из-за UWP. Я почти уверен, что Microsoft хочет, чтобы я ненавидел С# и XAML.

... или знаете какие-либо способы ускорить разработку?

Я переношу свое приложение в UWP, но я не могу прекратить поддержку Win8. Итак, у меня есть оба проекта в одном решении. Для меня, чтобы ускорить работу, я изменил конфигурации сборки на "Debug-UWP" и "Release-UWP", чтобы исключить приложение и проекты Win8, когда я работаю с приложением Windows 10. Это лишь незначительное облегчение. Строительство по-прежнему является болезненным опытом.

И

Вы можете отключить NuGet от восстановления пакетов при каждой сборке. Откройте "Параметры" > "Диспетчер пакетов NuGet" и снимите флажок "Автоматически проверять недостающие пакеты во время сборки в Visual Studio". Это также незначительно, но каждый бит помогает.

Ответ 2

Только мои 2 цента, но недавно я обнаружил, что существует большая проблема при работе над проектом UWP.

Я работал над своим проектом с Xamarin, чтобы иметь приложение, совместимое с Android/iOS/WP8 и UWP.

Но недавно работая в Visual Studio 2015 Update 2 (с W10), у меня были очень медленные характеристики, очень лаконичный интерфейс, Build, Debug, XAML, все было очень медленно.

Тогда я только что обнаружил что-то очень ужасное: если вы установите проект UWP в качестве стартового проекта вашего решения, Visual Studio 2015 станет медленным, как черт! Я не являюсь реальной проблемой, но для меня это была реальная проблема!

Я установил свой проект запуска в другом проекте в решении, кроме UWP и WP8. Если мне нужно отлаживать, я запускаю их, используя правый щелчок в проводнике решений, затем отлаживаю.

С тех пор VS2015 не имеет проблем с производительностью для меня.

Ответ 3

Увлекательный... просто захватывающий.

Отключите "Скомпилировать с цепочкой инструментов .NET Native" в свойствах сборки основного приложения UWP. Библиотеки UWP, похоже, не предлагают собственную опцию цепочки инструментов.

Я боролся с проблемой того, почему приложение для разбора файлов занимало в два раза больше времени, чем выполнение (не сборка) в качестве сборки релиза, чем как сборка отладки. Совершенно противоположно тому, что должно было произойти. Мне также приходилось замечать длительное время, чтобы завершить сборку релиза, но пока это была второстепенная проблема.

Если вы посмотрите окно вывода во время полной перестройки, вы заметите, что все библиотеки, которые у вас есть, будут построены так же быстро, как вы привыкли. Тогда основное приложение будет тем, что болото - LOT.

Проверьте свойства сборки для своих проектов и обратите внимание, что только основное приложение UWP имеет опцию "Компилировать с помощью .NET Native tool chain". В библиотеках этого нет. Кроме того, по умолчанию только релизная сборка включена. Отладочная сборка не работает. Разумеется, отключите его в сборке релизов, и сборка релизов начнется так быстро, как сборка отладки.

Тогда странность странности... моя сборка приложений для UWP теперь работает на 10% быстрее, чем версия отладки, когда она запускалась почти в два раза медленнее.

Это все очень контрастно интуитивно. Самородная сборка должна работать так же быстро, если даже не немного быстрее, чем неродная сборка. У компилятора под Visual Studio, безусловно, есть возможность более интенсивно работать над оптимизацией сборки для процессора.

Интересно, есть ли что-нибудь еще о проблемах с встроенными инструментами построения и есть ли объяснение. Медленное время сборки, которое я могу полностью понять, если инструменты сборки измельчают намного сложнее, пытаясь оптимизировать конкретный собственный процессор. Однако тот факт, что нативный код работает значительно медленнее, чем не-собственный код, полностью противоречит интуиции. Кажется, не имеет смысла, что MSFT бы захотела выпускать собственные инструменты сборки в таких обстоятельствах, что заставляет задуматься, используются ли инструменты неправильно или какое-то другое недоразумение - это a'foot.