Visitar URL original
perf(trimming): Require a constructor for linker hint availability by MartinZikmund · Pull Request #26054 · unoplatform/uno · GitHub
Skip to content

perf(trimming): Require a constructor for linker hint availability - #26054

Closed
MartinZikmund wants to merge 2 commits into
masterfrom
dev/mazi/wasm-linker-hint-ctor
Closed

MartinZikmund wants to merge 2 commits into
masterfrom
dev/mazi/wasm-linker-hint-ctor

Conversation

@MartinZikmund

@MartinZikmund MartinZikmund commented Nov 4, 2026 •

Copy link
Copy Markdown
Member

GitHub Issue: closes #26048

PR Type:

🐞 Bugfix

What changed? 🚀

With UnoXamlResourcesTrimming, LinkerHintGeneratorTask counted a DependencyObject type as available whenever its TypeDef survived a linker pass. An is check is enough for that. The bindable metadata then constructed the type and kept its whole implementation: in a blank app, RichEditBox (with its RTF codec and System.Text.Encoding.CodePages) and ~110 other controls nothing creates.

A concrete type now also needs a kept instance constructor. Abstract types keep counting, so their derived types' hints still hold. Controls instantiated by kept XAML still converge through the existing fixed-point passes.

Blank unoapp, WebAssembly Release, trimming on, brotli: −822 KB (Uno.UI −462 KB, CodePages −173 KB gone, FluentTheme −114 KB, Xml −42 KB).

Validation:

  • Runtime: a 20-control page (TextBox, ComboBox with its popup open, ListView, Expander, InfoBar, NumberBox, RichTextBlock, …) built with old and new hints differs by 0.006–0.017% of pixels (the animating ProgressRing), while shipping 600 KB less.
  • Unit tests: Given_LinkerHintGeneratorTask (4).

Measurements

Without this PR With this PR Δ
Download (brotli) 7.35 MB 6.42 MB −926 KB
4G visually ready 7813 ms (7791–7814) 6976 ms (6961–6995) −837 ms (−10.7%)
Local visually ready 892 ms (887–1090) 852 ms (844–868) −40 ms (−4.5%)

Size detail on the earlier base (blank app): Uno.UI −462 KB, System.Text.Encoding.CodePages −173 KB (gone), Uno.UI.FluentTheme −114 KB, System.Private.Xml(.Linq) −42 KB. A 20-control page: −600 KB.

How this was measured

Blank dotnet new unoapp (Skia, net10.0-browserwasm, Release publish), built twice from the same tree: with all six startup PRs (#26054–#26059) plus UnoXamlResourcesTrimming, and with only this PR's change removed. Both builds were served by the same static server (brotli q11, immutable caching for fingerprinted files) and loaded cold in headless Chrome, runs interleaved. "Visually ready" is the first CDP screencast frame identical to the settled final frame. 4G = 9 Mbps down, 85 ms RTT (CDP emulation). Values are medians with (min–max). A difference is only claimed where the ranges don't overlap. Rig: Playwright + Node, available on request.

PR Checklist ✅

  • 🧪 Added Runtime tests, UI tests, or a manual test sample (for bug fixes / features, if applicable)
  • 📚 Docs have been added/updated following the documentation template (for bug fixes / features)
  • 🖼️ Validated PR Screenshots Compare Test Run results.
  • ❗ Contains NO breaking changes
  • 👀 Reviewed 2 other open pull requests (optional but appreciated!)

Apps that create controls only through XamlReader with trimming on were already unsupported (see the resources-trimming docs). This change makes "only type-checked" controls fall in the same bucket.

🤖 Generated with Claude Code

https://claude.ai/code/session_01TXMNu2RupRy4QPFGK2cmij

MartinZikmund and others added 2 commits November 4, 2026 19:24
A DependencyObject type counted as available whenever its TypeDef
survived a linker pass, which any `is` check or field type is enough
for. The bindable metadata then constructed it and kept its whole
implementation: in a blank app RichEditBox (with its RTF codec and
System.Text.Encoding.CodePages), TextBox, ComboBox and ~110 others.

Concrete types now need a kept instance constructor. Blank WebAssembly
app with UnoXamlResourcesTrimming: -822 KB brotli (Uno.UI -462 KB).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TXMNu2RupRy4QPFGK2cmij
@github-actions github-actions Bot added the area/code-generation Categorizes an issue or PR as relevant to code generation label Nov 4, 2026
@unodevops

Copy link
Copy Markdown
Contributor

🤖 Your WebAssembly Sample App stage site is ready! Visit it here:

@MartinZikmund

Copy link
Copy Markdown
Member Author

Heads-up: with this change, an ItemsView without an ItemTemplate rendered empty in a trimmed build, because its default template created ItemContainer only through XamlReader.Load. Fixed in #26071, which should land first or together with this one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area/code-generation Categorizes an issue or PR as relevant to code generation

Projects

None yet

Development

Successfully merging this pull request may close these issues.

XAML resource trimming keeps controls that are only type-checked

2 participants