[WASM] Is Uno WASM a viable option for LineOfBusiness (LOB) applications?

[DierkDroth]

Hi,

I ran some tests using the UNO Gallery app.

Here are my findings (latest Chrome on latest Windows 10 using a 1GB line):

• Chrome console says "~26MB transferred" on each start
• startup takes 8-10 secs until the first content is visualized
• forcing a fresh reload (CTRL+F5) and restart does not change much on these numbers
• VS 2022->Analyze->Calculate Code Metrics on Uno.Gallery solution (I deleted all heads, only left the WASM head) says ~1230 lines of executable code

I'm trying to get a grasp on what this means for a non-trivial LOB app (e.g. my app has > 30K lines of executable code and still is not large by any stretch)

• why does UNO WASM not benefit from the browser cache (at all? noticeably?), neither in amount of data transferred nor in startup time?
• even the (relatively small?) Uno Gallery app has a significant startup time which is way longer than what the average user would expect/tolerate (2-3 secs)
• considering any "real world LOP app" I'm worried the numbers which had to be expected there

What's UNO's stance on these findings? What could be done to improve the startup experience?

Thanks in advance for shedding some light

[jeromelaban]

We've been working in performance for the upcoming Uno 4.1 update, and the gallery application will benefit from these changes.

This particular app is a showcase which is currently not using Profile guided AOT (hence the 26MB), is using both Material and Cupertino styles (it's generally not the case in normal apps), and is not yet updated to Uno 4.1. Updates will be coming soon.

Finally, .NET 6 still has issues (dotnet/runtime#60247) with AOT and interpreter/AOT boundaries which are being worked on for .NET 7. We expect that when these paths are optimized, runtime performance will increase significantly.

Each app has its own performance characteristics, I suggest to try out uno with your code to find out which and let us know.

[jeromelaban]

Yes, if you exclude Uno.UI from the linker, XAML resource trimming is not going to work. In general, you should not put Uno.UI there. Linker being enabled in release or debug is your choice in the csproj.

[DierkDroth]

@jeromelaban pardon my ignorance, but I'm trying to get 100% clarity on how this works.

I'm aware of this. So basically what I have in my linkerConfig.xml means:

• all assemblies listed as per above in my linkerConfig.xml are in 'preserve=all' mode
• this mean they would not touched by any tree-shaking logic at all
• they also would not be touched by any XAML resource trimming

Is that correct?

Next question then: why would I want to have any file in linkerConfig.xml in the first place? Wouldn't it rather make sense to start 'with nothing' and only add assemblies in case I ran into trouble? Or do we know already that some assemblies 'no matter what' should not be touched by tree-shaking nor XAML trimming?

[jeromelaban]

Assemblies placed in the linker config are force to be kept entirely in the resulting payload, including XAML resource trimming.

You'll want assemblies in the linker config to avoid reflection related issues, generally by the method specifically, but we do not give guidelines for that as it's up to the library authors to handle this.

As I mentioned previously, you do not need to place any of Uno's assemblies there, those are linker-compatible.

[DierkDroth]

Thanks for your patience @jeromelaban

A few comments:

• I recommend adding some explicit documentation on what to do (or not) to configure the linker. This definitely could help the less experienced users like myself who have little understanding what's going on behind the scenes when building UNO WASM and don't know which setting is where and impacts what
• I just tested latest templates: linkerConfig.xml holds this line <assembly fullname="Uno.UI" /> which is - according your comments above - not needed (please correct me if I'm wrong). I recommend removing that line from the templates.
• I would add the preserve="all" parameter to the linkerConfig.xml template, since it's more verbose than omitting it and makes it clearer what's going on

[DierkDroth]

Latest findings after removing UNO.UI from linkerConfig.xml + adding <UnoXamlResourcesTrimming>true</UnoXamlResourcesTrimming> to the section below (project file):

• initial download: 22.1 MB
• CTRL+F5: 14.5 MB

-> only small improvement. Appears tree shaking and resource trimming does not do much to UNO.UI

<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|AnyCPU'">
         <PlatformTarget>x86</PlatformTarget>
	 <UnoXamlResourcesTrimming>true</UnoXamlResourcesTrimming>
	 <WasmShellMonoRuntimeExecutionMode>InterpreterAndAOT</WasmShellMonoRuntimeExecutionMode>
</PropertyGroup>

[DierkDroth]

FYI summary of what I have so far:

• latest UNO packages as per screenshot below
• using an AWS S3 bucket as web space
• started uncompressed with ~86MB download size
• download size now is down to ~22MB due to:
  -- Brotli compression
  -- relatively small gains (details above) by IL Linker and XAML resource trimming

I'm shying away from PG-AOT for now, since I do have performance concern. However, I'll look into again as performance improves on our way to .NET 7