18

Does anyone else there have any issues with a very sluggish development experience in VS 2015 writing apps for the Universal Windows Platform 10? Compiling, debugging, even switching between windows is painfully slow compared to working with a similar, basic WPF application.

I have not been able to find any mention of this experience on Google, which leads me to wonder if there's something in my setup that is throwing a monkey wrench into UWP dev.

Has anyone experienced this, or know of any ways to speed up development?

Update

The context of this question is compiling in DEBUG mode, not RELEASE (.NET native) mode.

BCA
  • 7,776
  • 3
  • 38
  • 53

3 Answers3

5

Just my 2 cents, but i recently discovered that there is a big issue when working on UWP project.

I was working on my project with Xamarin in order to have an app compatible on Android / iOS / WP8 and UWP.

But working in Visual Studio 2015 Update 2 (With W10) recently, i had very slow performances, a very laggy interface, Build, Debug, XAML, everything were very slow.

Then i just discovered something very awful: If you set your UWP project as the starting project of your Solution, Visual Studio 2015 become slow as hell ! I don't what is the real issue but this has been a real issue for me!

I set my startup project on an other project in the solution, other than UWP and WP8. If i need to debug, i launch them using right click in the solution explorer, then Debug.

Since then, VS2015 has no performance issue for me.

Guillaume ZAHRA
  • 321
  • 4
  • 9
4

Fascinating... simply fascinating.

Turn off "Compile with .NET Native tool chain" on the Build properties of the main UWP app. UWP libraries don't appear to offer the native tool chain option.

I was fighting the issue of why my file parsing application took about twice as long to execute (not build) as a release build than as a debug build. Completely the reverse of what should have happened. I also happened to note the long time to complete the release build, but it was a secondary issue for the time being.

If you watch the output window during a complete rebuild, you'll note any libraries you have will build as quick as you're used to. Then the main app will be the one that bogs down -- a LOT.

Check the Build properties for your projects and note only the main UWP app has the "Compile with .NET Native tool chain" option. The libraries don't have it. Also, by default only the release build has it enabled. The debug build doesn't. Sure enough, turn it off on the release build and the release build starts completing as fast as the debug build.

Then strangeness of strangeness... my UWP app release build now runs about 10% faster than the debug version when it used to run nearly twice as slow.

This is all VERY counter-intuitive. A native build should run just as fast, if not even a tiny bit faster, than the non-native build. The compiler under Visual Studio certainly has the option of putting much more hard work into optimizing the build for the processor.

I wonder if there is anything else published about problems with the native build tools, and whether there's an explanation. The slow build time I can understand completely if the build tools are munching away a lot harder trying to optimized for the specific native processor. However the fact the native code runs dramatically slower than the non-native code is completely counter-intuitive. It doesn't seem to make sense that MSFT would have bothered to release the native build tools under such circumstances, which leads one to wonder if the tools are being used incorrectly or some other misunderstanding is a'foot.

kburgoyne
  • 181
  • 1
  • 2
  • I have also found this head-scratching behaviour with runtime performance between Debug vs Release builds. I have a GridView page that takes 3 seconds to render with a Debug build, and a tedious 5 seconds with a Release build. However, I could be wrong but I believe if you are putting your app in the Windows Store, it will get compiled with the .NET Native tool chain in the end – BCA Apr 13 '16 at 12:48
  • I seem to remember reading somewhere that if you're relying on code that makes use of Expressions (e.g. something like JSON.NET) then your release code may end up being slower, the reason being that they can't be JITted as with the non-native build, rather they have to be interpreted. – Mike Goatly Apr 26 '16 at 16:03
2

Update Oct 2016

This answer is no longer relevant, as of Visual Studio 2015 Update 3. Microsoft have done a great job bringing the development environment back to a stable state. Although I currently have issues with the XAML designer, coding & building is much faster and more enjoyable. I hope most of the debilitating issues found in the XAML designer are resolved in the next Visual Studio 15.

Has anyone experienced this

Yes.

Everyone on my team is losing hair because of UWP. I'm almost convinced that Microsoft wants me to hate C# & XAML.

...or know of any ways to speed up development?

I'm porting my app to UWP but I can't end support for Win8. So, I have both projects in the same solution. For me, to speed things up, I modified the build configurations to "Debug-UWP" and "Release-UWP" to exclude the Win8 application and projects when I'm working with the Windows 10 app. This is only a minor relief. Building is still a painful experience.

Also

You can disable NuGet from restoring packages on every build. Go to Options > NuGet Package Manager and uncheck "Automatically check for missing packages during build in Visual Studio." This is also minor, but every little bit helps.

Laith
  • 6,071
  • 1
  • 33
  • 60
  • Although there is no workaround presented (at this point I presume there is no way to make things faster), thanks for at least letting me know I'm not alone in sluggish UWP dev. – BCA Sep 30 '15 at 16:45
  • @ARandomGuy, I love it too, believe me. I have high hopes for it. – Laith Sep 30 '15 at 20:15