Aspnetcore: We needed to talk performance

[DierkDroth]

Hi,

We're investing significant effort in migrating our fat client .NET app to the web. Obviously we're very excited about wasm and Blazor and already made our business logic .NET Standard 2.0 compliant. In the last few days our prototype showed the first signs of life. However, we immediately hit a road block/show stopper ...

Sorry for being frank, but performance is a desaster

Details:

• we found (using StopWatch) that our business logic is executed >= 100x slower on wasm/Blazor than on desktop/.NET framework
• we initially were in a disbelieve, but confirmed those findings by some simple/crude performance benchmarks

As per FAQ I understand that the app is not compiled but MSIL code is 'interpreted' by the .NET runtime (which is compiled to wasm) as wasm binary. The compile option only is rendered as 'may be'.

Questions:
1) are our performance findings accurate or are we missing something?
2) if our findings are accurate: what is the path for Blazor to overcome that performance show stopper?

Thanks in advance

[redowl3]

Pretty sure performance is being looked at in future versions of Blazor/Mono but why have you got business logic in your UI?

[DierkDroth]

May be it's not clear, but wasm now is a significant step towards removing the separation between desktop apps and web apps. It allows for having fat/rich client logic in the web (browser) and - through mono-wasm - for having the same C# code base for desktop and web apps.

Also: even our UI logic is - due to custom rendering on HTML canvas - non trivial and requires massive code stacks.

However, this is besides the point of my original inquiry...

[redowl3]

I understand what wasm is and what it could offer, but still don't get why you would put business logic in the UI of what is still a web app? Sure somebody will help with the performance issue.

[SteveSandersonMS]

Your performance findings most likely are accurate for the time being. So far the priority for Mono has been around core functionality rather than perf optimisation. Likewise in Blazor the perf-focused work we've done has been based around principles from desktop .NET (such as minimising heap allocations and building a lot of the internals around immutable structs). This has generally led to decent results for UI rendering, which is of course the key feature for Blazor, but I can't make any claims that CPU-intensive business logic should run fast right now.

I understand the Mono team has some big perf-related features underway, most notably AoT compilation. When this is done we should have a clearer idea of what sort of perf characteristics to expect in the short term. You can discuss this on the Mono repo if you want to know more.

Bear in mind that Blazor is an experimental project at this stage. It will only get significant investment if it's commissioned as a product. Until then our effort focuses on understanding the desired capabilities and developer experience, not the performance of arbitrary non-Blazor-related code. Hope that's OK!

[MihaMarkic]

@redowl3 Why not? Fat client is usually faster and friendlier, plus it requires less server side resources. I'm sure that Blazor will eventually run at least decently fast.

[DierkDroth]

@SteveSandersonMS thanks for shedding some light.

I understand that Blazor is dependent on Mono support for wasm and - as you pointed out - the Mono support for AoT compilation. However, does this mean Blazor would be committed to support AoT after it's provided by Mono?

[SteveSandersonMS]

@DierkDroth Nobody's committing to anything at all at this stage. But if Mono AoT makes things faster then, if we can support it, I certainly expect we'd want to.

[DierkDroth]

In case someone is interested: https://github.com/stefan-schweiger/dotWasmBenchmark

[paritosh149]

Based on link shared by @DierkDroth , C programs seem to be clear winner in performance measurements. How about Compiling Apps with .NET Native for performance improvement?

[chucker]

.NET Native doesn’t run in WASM.

[paritosh149]

C programs compiled to native code runs on webassembly. I need to understand more about differences between C Native programs and .NET Native programs.

[Suchiman]

@paritosh149 mono is working on full AOT support for webassembly, they have full AOT support via LLVM backend already but they need full AOT via a emscripten backend which they're working on. In that case you get IL -> mono AOT -> LLVM Bitcode -> emscripten -> WASM. Currently only mono is compiled via emscripten and runs IL via bytecode interpreter which is slow.

[vertonghenb]

@paritosh149 , a good start could be the technical introduction of Blazor by Steve Sanderson, which can be found here: http://blog.stevensanderson.com/2018/02/06/blazor-intro/

[paritosh149]

Thanks for clarity on the concerns. Really Helpful. I find blazor as a step in right direction but long way to go. 👍

[LyonBlecher]

I think the reality is that you should never have application business logic in your front end. I think the power of blazor is the seamless nature of writing c# that runs on the client, and how seemless it becomes to do client specific tasks and dom manipulation using c#, with less reliance on all these javascript frameworks. The server side blazor project excites me the most with signalR and dom diff handling all the client server communication, lightening the load on the developer. Also full stack development in mostly the same language opens up web development to users who are scared, or dont have the experience or time to learn the multitude of javascript and web frameworks out there.

[MihaMarkic]

Fat client, thin client both have pros and cons. I don't see why one should be limited of any of them. Also making Blazor faster would benefit both.