Discussion: WINUI 3.0 and XAML *Compile* Performance

[dbeavon]

Discussion: WINUI 3.0 and XAML Compile Performance

There was another discussion about XAML performance (runtime performance of xaml rendering). I didn't want to hijack that completely ... so I am opening this separate discussion about xaml compiler performance.

Here is the starting point for the discussion. @jtorjo said :

uwp compilation times are insanely slow! (pretty much, 6 times slower that WPF - i'm using target version build 1809 - build 17783)

I definitely agree. Debug/run iterations (development "inner loop") is quite slow compared with wpf or winforms, or most other U/I technologies. This productivity hurdle seems to be primarily related to the compilation of uwp-xaml. The performance of compiling uwp-xaml took a big turn for the worse after the "fall creator's update". There are many reports of performance troubles in the VS community including my own:
https://developercommunity.visualstudio.com/content/problem/376045/compilation-of-uwp-xaml-project-is-slower-when-tar.html

Not to be overly critical, but I really don't think Microsoft has started looking deeply at developer productivity of UWP on the .net side of things. Or at least they aren't directly tackling the compilation side of the problem. They have invested in other approaches for improved productivity like xaml edit-and-continue, and "xaml studio", etc. While these are helpful, they seem like workarounds and it seems like a lot more can be done.

After one of my community posts about performance, the developer tools team had made a statement, although I cannot find it anymore (maybe censored?) . The team had added the following statement to my developercommunity post. The statement tries to explain the regression after the fall creator's update: "This performance issue you that identified was introduced in an effort to address build consistency issues, especially in incremental compiler situations. With that in mind, we are looking at ways to make this better so the compile time impact is less."

Here are some of the community posts on the topic of UWP compile performance (there are many):

• https://developercommunity.visualstudio.com/content/problem/376045/compilation-of-uwp-xaml-project-is-slower-when-tar.html

• https://developercommunity.visualstudio.com/content/problem/692141/build-time-of-uwp-c-projects-takes-too-long.html

My understanding is that redundant iterations of the "CompileXaml" tasks are being executed by Visual Studio (ie. even more compilation passes than reasonable)

I think the most constructive thing we can do is to provide hard measurements (from the VS output window) to corroborate our anecdotal observations that the compilation of uwp-xaml projects is slow. There may not be enough feedback, nor metrics from C#/desktop developers yet. (I suspect there are not enough of us to begin with. I suspect that much of the developer base for UWP/WINUI is still C++).

Capturing hard measurements is critical. I'd recommend tuning your workstation and then compiling the "vanarsdel" sample project on github. There are two of them - a regular vanarsdel and a vanarsdel "inventory sample". You can compare to my results on stack overflow, and then post your own results as well: https://stackoverflow.com/questions/52919086/speeding-up-compilation-in-uwp

I also want to point out that I had asked the question about xaml compile performance in the first winui community call : #1478 ...

See the end of the video at 46:30. Someone named "Daniel" (Jacobson I believe) said they were going to try to improve performance for the "next version" of uwp/winui (see 47:30).

Related Links

• https://developercommunity.visualstudio.com/content/problem/376045/compilation-of-uwp-xaml-project-is-slower-when-tar.html

• https://developercommunity.visualstudio.com/content/problem/692141/build-time-of-uwp-c-projects-takes-too-long.html

• https://stackoverflow.com/questions/52919086/speeding-up-compilation-in-uwp

[danzil]

For the Alpha we released today we focused on bringing existing functionality up as soon as possible to get everybody's feedback. This release did not yet include the performance fixes we talked about before in a developer community thread (linked above). Now that the Alpha is out there, I want to assure everybody that those improvements are still pretty much plan of record for WinUI 3.0 and we are all committed to addressing them in this release. BTW, that Daniel on the call was me (not Jacobson).

[jtorjo]

@dbeavon I've compiled VanArsdel, on 17763 build. Note that at this time, I can't change the min version, since I get a compile error.

Build vanarsdel ,debug x64, build 17763

1>Project Performance Summary:
1> 12521 ms C:\john\code\buff__photawe\VanArsdel-master\VanArsdel\VanArsdel.csproj 1 calls
1> 12521 ms Build;BuiltProjectOutputGroup;BuiltProjectOutputGroupDependencies;DebugSymbolsProjectOutputGroup;DebugSymbolsProjectOutputGroupDependencies;DocumentationProjectOutputGroup;DocumentationProjectOutputGroupDependencies;SatelliteDllsProjectOutputGroup;SatelliteDllsProjectOutputGroupDependencies;SGenFilesOutputGroup;SGenFilesOutputGroupDependencies 1 calls

1>Task Performance Summary:
...
1> 0 ms Delete 2 calls
1> 114 ms Copy 5 calls
1> 134 ms WireUpCoreRuntime 1 calls
1> 263 ms GenerateResource 1 calls
1> 270 ms ResourceHandlingTask 1 calls
1> 316 ms ValidateAppxManifest 1 calls
1> 420 ms ResolveAssemblyReference 1 calls
1> 463 ms GenerateProjectPriFile 1 calls
1> 651 ms GenerateAppxManifest 1 calls
1> 684 ms GenerateAppxPackageRecipe 1 calls
1> 810 ms Csc 2 calls
1> 7380 ms CompileXaml 2 calls

[jtorjo]

@danzil This is amazing news! Any ETA when this may be addressed?

P.S. I can't target anything lower than 17763 in my app, because of my dependencies.

[danzil]

@jtorjo We plan to address this with WinUI 3.0 in 2020, which is planned to be able to target down-level to that SDK (roadmap).

[dbeavon]

@jtorjo looks similar to my results. There are two variations of this perf summary. One for the first compilation of a project and one that you see after making incremental changes to code/xaml. Both variations are about the same where "compilexaml" task is concerned.

The most discouraging thing that I had noticed is when I add the very first xaml control to a Uwp project and the compile time jumps up by 2 or 3 additional seconds (regardless the size or complexity of xaml). After only 1 or 2 dozen xamls , the project takes over 10 secs to compile and that is where I totally lose patience....

However I've heard die-hard developers say they wait 30 seconds or longer for their uwp-xaml to compile (per project). I don't know how you get anything accomplished at that point... I'd love to see the vs telemetry that identifies the devs who are the most "patient" . Uwp.net devs have to be up near the top of the list. ;-)

[jtorjo]

@dbeavon I totally feel you! That's what's killing me as well... I know I've seen somewhere on the internet (maybe it was you who said it) breaking up the UI into several assemblies.
I may end up doing just that...

As I've said in some other posts, I really need UWP, since I have to use win2d - so no matter how I slice and dice it, I still need to put up with those times.

@danzil That sounds really cool, I'm definitely looking forward to that! In the mean time, is there anything we can do to speed compilation times? I'm willing to create a RAM disk and install my SDK there on each reboot, assuming that would make a difference (@dbeavon have you tried that?)

[danzil]

Unfortunately, I don't know of any workarounds besides just installing the latest VS that has fixed a couple of regressions in that area a few months ago.

[dbeavon]

The ramdisk wouldn't perform much better than ssd. The bottleneck during builds is single-threaded CPU for a given project. (Although multiple projects might build in parallel if they are independent of each other.) I would invest in > 4 GHz CPU if possible and make sure none of that is being wasted on defender or telemetry/insights or whatever. There are several things you can do in your debug settings to improve the F5 launch a bit.

The best trick is to divide the code into smallish projects which compile in under 10 sec. If you have experience with WPF then you may know the trick to use a shared output directory and avoid compiling the startup project when it isn't actually changing. That trick is possible in Uwp as well but was touchy and took some effort. The end goal is to avoid waiting more than about 10 sec for F5. How long are you waiting?

[jtorjo]

@dbeavon I see... Yeah - I disabled Windows defender years ago. No telemetry either.

Dividing the code into smallish projects will probably be my best bet.

About the shared output directory: Is this what you're referring to: https://blogs.msdn.microsoft.com/kirillosenkov/2015/04/04/using-a-common-intermediate-and-output-directory-for-your-solution/ ?

I wasn't aware of it, since i never needed it. My WPF projects have always been fast to compile - a fresh compile of 28 WPF projects usually takes less than 15 seconds. So whenever I change something, it will probably be around 5s or less until the app starts.

On UWP, I have a project where all the UI is (xaml), and that takes around 15-20 seconds or so to compile. And another 6-7 seconds to deploy (sometimes a bit faster)

[dbeavon]

@jtorjo For instructions on setting a common output directory, see this:
https://docs.microsoft.com/en-us/visualstudio/ide/how-to-build-to-a-common-output-directory?view=vs-2019

I would create new/separate project configurations that are copied from your Debug ones. Call them DebugFromCommon or something and set the common output directory where you want all the outputs to go. Then create a DebugFromCommon solution configuration as the parent for these new project configs. Then rebuild the whole solution under the DebugFromCommon config. Then edit the solution configuration to uncheck "compile" for any of the projects you aren't actively working on (including the launch project).

After this is finished, your F5 will never compile projects that are not checked... even if some of the dependencies have been modified. The projects which are getting compiled will be dropped into the common output directory and will be ready for execution. Just remember to do a "fresh" rebuild of the entire solution to the common output directory once a day, and whenever you run into any unexpected issues like loader exceptions. Hope this is clear.

[jtorjo]

@dbeavon Sorry for the late reply - it's been hectic for me lately.
I followed your instructions.

The big "lightbulb" for me has been the check/uncheck of projects to build. I knew about this setting for years, but never truly needed it. But now that I think of it, I managed to uncheck 9 projects - so I'm only compiling 5. This, together with the deployment, boils down to 10-12 seconds until my app is up and running.

This is down from roughly 40-50 seconds, so it's a huuuge improvement. Thanks for the help!

[jtorjo]

@danzil About your post on #1517 : That's great! Is there any ETA when we'll have something?
As an FYI, the more recent of a Windows version you're targeting, the worse the compile time.

Right now, I'm targeting 1903, and just the deployment itself takes 6+ seconds! (no building at all). On 1809, deploment was less than 1 second.

Anything you can give us would be great - I don't mind creating a RAMDisk, whatever, just to speed up compilation times.

[danzil]

@jtorjo please add your voice to #1517, especially the numbers you've just listed. That helps us back the investment we're adding behind that effort. I wish I could give you a definitive ETA, but I can't. All I can say at the moment is that we've identified a substantial amount of design improvements we want to make and they're all queued up in our internal work item tracking system.

[jtorjo]

@danzil Done, thanks!

[danzil]

Looks like #2171 contains similar or identical feedback, but let's use this issue to track all WinUI Xaml compile performance issues. I'll turn this into a bug (we already have another internal deliverable tracking this work).

[roman-shpuntov]

Yes, the compile of xaml is take huge time... I have project without UI - no problem with compile performance, but XAML/UWP/C++ very long compilation.

[jimm98y]

I'd like to mention this issue here: https://developercommunity.visualstudio.com/content/problem/970383/uwp-app-build-takes-an-hour-and-vs2019-is-throwing.html?childToView=1043331#comment-1043331 Apparently, there is a huge performance degradation in VS2019 16.4+ and in our case it is causing 10 minutes delay between hitting "Run" and starting the application - with no code changes, just an incremental build of the EXE in Debug + deploy + run. Modifying Microsoft.AppxPackage.Targets as described in the solution helps, but the question is whether the issue is going to be fixed by some VS update (and which parts of XamlIslands and WinUI 3 are going to be broken by removal of the build steps in the targets file).

[jtorjo]

@jimm98y Reading the issue almost makes me cry. I feel ya! Apparently, my compile times are nothing compared to what you have, but it still drives me insane!

At MS Build, Microsoft said they will be working on compile times, but they need to also deal with winui 3. I really hope they'll do it really soon, since there will be quite a few iterations of winui 3 (as I understand, iteration 4 will be end of year) -- so are we supposed to wait another year until winui 3 becomes stable?

[zenjia]

I've just tested WinUi 3.0 preview(using Win32 desktop project). The compile time is still huge, even for a minimal project. It seems it's not UWP's problem. I believe the problem is with WinuI's developing language, i.e. c++. Really missing WPF now. Hope there will be a c# version of Winui in the future. What a pity!

[ChumIT]

Any update on this issue

[fabiant3]

Thanks everyone for your patience.

We are aware of the build performance issues. At this time, our team is focused 100% on bringing back WinUI tooling support in Visual Studio (primarily Live Visual Tree, Hot Reload). Once we complete that work, we should be able to look more into build pipeline performance improvements.
With that being said, @Scottj1s is getting starting to investigate pipeline performance, the goal being to find and rid off any low hanging fruit issues. He will be sharing out data once he has it.

[jtorjo]

Thanks everyone for your patience.

We are aware of the build performance issues. At this time, our team is focused 100% on bringing back WinUI tooling support in Visual Studio (primarily Live Visual Tree, Hot Reload). Once we complete that work, we should be able to look more into build pipeline performance improvements.
With that being said, @Scottj1s is getting starting to investigate pipeline performance, the goal being to find and rid off any low hanging fruit issues. He will be sharing out data once he has it.

Wow, this couldn't have come at a better time!

1. The Hot Reload - I've seen it's been broken for a while, so looking forward to having it fixed!
2. I was gonna write another looong thread about compilation issues. I'm not saying I'm most qualified to give you feedback on this, but I would say I'm pretty close. My app has 110K+ LOC without tests, and I've had to make sooo many workarounds to make this bearable.

Having said that, if anyone's interested, I could write another post detailing what I've found.

[rick-palmsens]

What is the status of this issue? We run into the compilation performance a lot. Our .Net Core projects only take seconds to compile, while our WinUI projects can easily take over a minute.

[Userlinger]

What can one do to give this issue more visibility? Honestly these excessive buildtimes ruin my development experience. I am forced to stick with WPF until this is fixed. I also heard this from several other developers who tried out WINUI 3.0 or UWP.

[roshannzth]

is there any update on this?
i am noticing in my win ui 3 c++ project, with lot of pages, build time is really high now.

========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
========== Build started at 03:47 PM and took 11:54.081 minutes ==========
A package has been successfully built for Release (x64).
========== Package: 1 succeeded, 0 failed ===========

[stegru]