Why is UWP 10 development so slow?

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.

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.

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.