Winui3 build performance

[curtis conner (cconner100)]

It great to hear that your working to make Winui3 faster.

Our issue with the winui3 system is really around the time it take to build and deploy. We have a WinUI3/Uno system today. We can build our app in native WinUI3 or in the Uno Desktop version.

The Uno Desktop version takes about ~5 mins to build.
The same code building with Winui3 take about ~30 mins to build and deploy. This is very frustrating and makes the complete development loop very slow and painfull.

Is there any efforts in trying to reduce this build time.

[Kevin Gallahan (kmgallahan)]

Do you have a million LOC, dozens of projects, or a build machine with a HDD rather than SSD?

My full solution rebuild in VS takes < 2 min for 4 WinUI 3 apps, 2 controls libs, and 16 .NET projects.

========== Rebuild All: 22 succeeded, 0 failed, 0 skipped ==========
========== Rebuild completed at 10:29 AM and took 01:22.566 minutes ==========

┌──────────┬─────────┐
│ Language │  Lines  │
├──────────┼─────────┤
│ C#       │ 147,833 │
├──────────┼─────────┤
│ XAML     │  24,436 │
└──────────┴─────────┘

[curtis conner (cconner100)]

Thanks for the reply.

We have i7 machines with 1tb ssd, 32gb ram. We are using a dev drive and have defender turned off on that drive.

Our project is a bit bigger

Type Files Physical lines. Nonblank lines
C# 5,791 811,602 683,474
XAML 347 63,009 59,550
Total 6,138 874,611 743,024

========== Rebuild All: 41 succeeded, 0 failed, 0 skipped ==========
========== Rebuild completed at 12:18 PM and took 47:02.808 minutes ==========

If you would like any more information please ask, as you can see 47minutes for a build is huge. It makes the debugging the system almost impossible.

curtis

[Kevin Gallahan (kmgallahan)]

I'd recommend getting a binlog and viewing the contents on a timeline:

MSBuild.exe MySolution.sln -t:Rebuild -restore -p:Platform=x64 -bl:MySolution.binlog -v:m -nologo -nodeReuse:false

Could also use Configuration=Release to see how the timings change.

Timeline viewer: https://msbuildlog.com/

[junyi96]

There is agent skills for binlog in dotnet-msbuild to help with checking build times.
https://github.com/dotnet/skills

[curtis conner (cconner100)]

here is the binlog
https://1drv.ms/u/c/57fc91bd0034689d/IQARPvW-6M0IRoIkc0Lbhge-AcRgCraz3WbBiojTa7VjKo8?e=lRc4Ws
its on a one drive since it 401mb compressed

[Kevin Gallahan (kmgallahan)]

If you add -m then the time spent compiling C# and XAML will go down if/when you create another binlog or build outside of VS (this parallelizes the build, which VS does automatically so it won't help there, but VS is also doing a deploy which adds time on top).

Otherwise, per Claude:

TL;DR: Your ~45-min serial build is roughly C# compile ~17 min + XAML compile ~5 min + MSIX packaging ~8–10 min + copy-local ~5 min. The C# part isn't WinUI-specific (it's source generators/analyzers, and your Skia build pays it too). The packaging part is slow for a concrete, fixable reason: your package payload is ~570,000 files, ~92% of them images, and those same images also inflate the copy-local step. None of the fixes below require changing your assets.

I replayed your binlog through a streaming reader and summed time by phase (it's too big to open in the msbuildlog.com viewer — it maxes RAM). It ran serially on one node. Here's the breakdown, then what each phase actually is:

Phase	~Time (serial, self-time)	WinUI/WASDK-specific?	What drives it
C# compilation	~17 min	No — runs in your Skia build too	source generators + analyzers over ~5,800 .cs files
XAML compilation	~5 min	Yes	WinUI XAML markup compiler over ~350 .xaml files
MSIX packaging (+ PRI/MRT)	~8–10 min	Yes	a ~570,000-file payload — ~92% images
Copy-local / file-tracking	~5 min	No, but…	also ~95% those same images

1. C# compilation — ~17 min (not really a WinUI cost)

CoreCompile — Roslyn compiling your ~5,800 C# files across 67 inner-builds at ~13 s each. The bulk of that per-file cost is analyzers + source generators, not raw compilation. This is your single biggest bucket, and it runs in your 5-minute Skia build too, so it isn't WinUI/WASDK-specific. To see which generators/analyzers dominate, rebuild once with -p:ReportAnalyzer=true — the binlog then itemizes per-analyzer/per-generator time.

2. XAML compilation — ~5 min (WinUI-specific)

The WinUI XAML markup compiler (MarkupCompilePass1/2 + XamlPreCompile) turning your ~350 .xaml files into binary .xbf + generated code, in two passes. Your Skia head does XAML as a source generator and pays ~0 here, so this is a genuine WASDK cost — proportional to XAML volume.

3. MSIX packaging — ~8–10 min (WinUI-specific; this is the surprising one)

The payload your build assembles and PRI-indexes is ~570,000 files:

File type	Count	% of payload
image — DPI scale/qualifier variants (.scale-200, .scale-150, …)	449,308	79%
image — base (.png/.svg/.ico/…)	74,914	13%
compiled XAML (.xbf)	17,282	3%
PRI index (.pri)	8,445	1.5%
DLL	6,719	1.2%
XAML / pdb / winmd / fonts / …	remainder	<3%

~92% of the package is images, and 4 of every 5 files are generated DPI scale variants. The math: ~75,000 base images × ~6 scale/qualifier variants each (scale-100/125/150/200/400 …) ≈ 450,000 generated files, produced automatically by MRT.

Why that's slow:

• Every packaging step re-materializes this ~570K-item list, dozens of times (PackagingOutputs 80×, the MRT cross-project list 25×).
• Several item operations are O(n²) at this size — one collection runs RemoveItem ~5,000× against an 88K-item list, plus full exclude/filter passes over 569K items. Quadratic item algebra over half a million entries is where the minutes go.

For reference, a typical app's payload is a few hundred to a few thousand files. WinUI packaging is slow at ~570K files — but nearly any packaging system would be. This is the part of "WinUI is slow" that's really "the packager is indexing ~570K files every build."

…and it spills into copy-local too (~5 min)

The graph-walk/copy-local time is tied to the same images:

• FileWrites / the Copy task: 73,491 files, ~95% images (60K scale variants + 10K base)
• _PriInputs (PRI indexing): 79,522 files, ~86% images
• the transitive child-item list (the one hit with ~5,000 RemoveItem passes): 88K files, ~41% images / ~48% DLLs

So this asset set is copied, clean-tracked, and PRI-indexed, not just packaged — it inflates three of the four buckets. Only C# and XAML compilation are independent of it.

What to do — short-circuit the per-build packaging

The goal isn't to change your assets; it's to stop the pipeline from enumerating ~570K files every build. Options, cheapest → most durable:

1. Run the inner loop unpackaged (WindowsPackageType=None). For daily dev, build/run unpackaged — the whole MSIX pipeline (payload assembly, the 570K iteration, PRI packaging, appx creation, and deploy/register) is skipped; assets resolve as loose files. Biggest, cheapest relief; dev-loop only (you still build the MSIX for release, just rarely). Caveat: a few package-identity APIs behave differently unpackaged.

2. Move the asset set into a separate prebuilt resource/optional package. Build the big asset set once into its own MSIX resource (or optional) package and reference it; the main app's every-build packaging stops enumerating those files. Helps release and dev; more setup (the package + runtime resolution), but it's the durable fix.

3. Take the assets out of MRT/PRI and load them as loose files by path. Instead of ms-appx:/// PRI-managed resources, ship the asset folder as plain content (or deploy it separately) and load by path at runtime — they never enter PackagingOutputs/PRI, so packaging permanently iterates thousands instead of 570K. Trade-off: you handle DPI selection yourself rather than MRT.

4. Generate fewer DPI scale variants. A build-property change so each image emits ~1–2 scales instead of ~6 cuts the payload (and the copy/PRI lists) ~3–6× — same source images. Trade-off: lower crispness at the dropped DPIs unless the source is vector, so this one does affect output. (Exact property differs between WinUI content qualifiers and the Uno Resizetizer.)

A sensible combination: #1 immediately for the dev loop, plus #2 or #3 as the lasting fix, with #4 as a knob to be aware of. And independently — confirm your daily builds are incremental, not full rebuilds; a Rebuild re-does all of the above, whereas an incremental build should skip most of the packaging when nothing changed.

[HO-COOH]

Looks like C++WinRT build performance is so bad that no one even talks about it. An empty winui3 C++ project (created with the visual studio project template) takes a solid 1 min to build even on a middle-end 8 core PC

[Yexuan Xiao (YexuanXiao)]

https://developercommunity.visualstudio.com/t/C20-modules:-CompileAsCppModule-items/11114019

https://developercommunity.visualstudio.com/t/C-build-adds-unused-module-ifc-refere/11125582

https://developercommunity.visualstudio.com/t/C20-modules-compilation-underutilizes/11107431