Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Experiment] Running Avalonia Browser on NativeAOT-LLVM #16211

Open
1 of 8 tasks
maxkatz6 opened this issue Jul 3, 2024 · 6 comments
Open
1 of 8 tasks

[Experiment] Running Avalonia Browser on NativeAOT-LLVM #16211

maxkatz6 opened this issue Jul 3, 2024 · 6 comments

Comments

@maxkatz6
Copy link
Member

maxkatz6 commented Jul 3, 2024

Intro

While Mono provides stable support for WebAssembly in Avalonia, we were planning to investigate NativeAOT-LLVM for a long time. Recently several JSImport/JSExport related changes were backported to NativeAOT-LLVM branch, making it much easier to reuse the same Browser backend code (literally zero code changes, but with nuances).

After dealing with all the issues, refactoring part of SkiaSharp/HarfBuzzSharp, and doing it again but differently, I was able to get it running really well. As a surprise, even WebGL works (at least after SkiaSharp refactoring).

Biggest differences in app experience, comparing to Mono runtime, are:

  • Much faster startup time. On a hello world app it's nearly instant, I would say excellent for a browser. ControlCatalog is poorly optimized on our side, but even then, it starts pretty quick.
  • Much bigger bundle size. LLVM version is near 95mb, Mono AOT is near 50, Mono without AOT is just about 25. Unzipped and uncompressed both. Note, I used default build parameters for the most part. Excluding debug information from the build creates 40mb bundle for NativeAOT-LLVM.
  • Performance difference is hard to tell. While some heavy pages are opening slightly faster, it's hard to get numbers, as we don't have any e2e benchmarks that can be run in browser.

Pending issues

NativeAOT-LLVM:

SkiaSharp:

Other relevant issues:

How to test

I have built ControlCatalog with three different configurations.
NativeAOT-LLVM: llvm.zip
Mono, default: mono.zip
Mono, AOT: mono-aot.zip

But you also can clone Avalonia and checkout nativeaot-llvm-experiment branch.
ControlCatalog.Browser then can be built via:

dotnet publish -p:UseNativeAotLllvm=false -r browser-wasm
dotnet publish -p:UseNativeAotLllvm=true -r browser-wasm

Note, it requires locally built SkiaSharp and HarfBuzzSharp, as my changes weren't yet merged.

cc @yowl @SingleAccretion @maraf and @mattleibow

@maxkatz6
Copy link
Member Author

maxkatz6 commented Jul 3, 2024

Some video running both Mono and NAOT-LLVM versions as well

browser.mp4

@hez2010
Copy link
Contributor

hez2010 commented Jul 3, 2024

Can you try adding /p:NativeDebugSymbols=false /p:StackTraceSupport=false while publishing the app?
Currently NAOT-LLVM will embed all debug symbols into the binary which can contribute a lot of binary size.

@hez2010
Copy link
Contributor

hez2010 commented Jul 3, 2024

Update: by applying /p:NativeDebugSymbols=false /p:StackTraceSupport=false, it yields a bundle size for about 40.4mb (all pdb and xml documents removed), which is a lot smaller than Mono AOT.

@AmSmart
Copy link

AmSmart commented Jul 3, 2024

Wow, Native AOT is super impressive

@maxkatz6 maxkatz6 self-assigned this Jul 4, 2024
@hez2010
Copy link
Contributor

hez2010 commented Jul 7, 2024

Here is the one built with debug symbols stripped:
ControlCatalog.Browser.zip

And with brotli compression, the total size becomes smaller than 10mb!

@JaggerJo
Copy link
Contributor

Here is the one built with debug symbols stripped:

ControlCatalog.Browser.zip

And with brotli compression, the total size becomes smaller than 10mb!

That's quite impressive!

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

No branches or pull requests

4 participants