Need Blazor Wasm Performance Improvement on CPU Intensive Calculations

user_858533 0
Viewed 2525

I have a c# WinForms app that I have been converting to Blazor Wasm. It needs to perform a set cpu-intensive calculations (i.e. no IO or UI interaction) after most user inputs. The calculations entail repetitively (30-50 times) invoking a number of methods in a set of 25-35 C# class objects depending on the scenario. The same calculation code runs in the WinForms and Blazor apps.

I am seeing a ~20 fold degradation in performance under Blazor (e.g. 350ms in WinForms vs 7000ms in Blazor). Does that level of degradation make sense? Is a big part of it inherent to running within a browser? Is Blazor Wasm a big part of it somehow? I have confirmed that the degradation is spread across the calculations, not in isolated spots. Are there any ways to significantly reduce the degradation? The objects that perform the calculations could be put in a class library if that might help for some reason.

I have posted this question in the AspNetCore Discussions in GitHub, but have had no responses. I am using VS Community 2019 v16.8.2, AspNetCore 5.0, and Chrome v

Thanks. Steve

webassembly blazor asp.net-core visual-studio c#
7 Answers

This is a very late response to this question, but would web workers help to resolve this issue? This should bring some multi-threaded capability to the table. I can't speak to implementing this myself, but here's one helper library that appears to bring this into Blazor fairly easily:

https://github.com/Tewr/BlazorWorker

In native JavaScript you can access the core count of the browser through the Navigator Api:

const coreCount = window.navigator.hardwareConcurrency;
console.log(`Your computer has ${coreCount} cores!`);

user_42820810

Blazor Wasm does not support multi threading + frequent actions like mouse event handling are very 'heavy' for processing in a browser. Try to push action handlers in a queue and process them in background.

user_126623010

If you have a .NET backend, you can easily execute the code there instead. With a few milliseconds overhead, you get almost the same performance as before. One of the benefits of using the same language on both sides.

user_148522970
user_42657420

There are two hosting models with Blazor: Blazor CLient and Blazor Server model. Details here: Blazor Hosting Models I would expect such degradation if you use Blazor Client side but would not expect it in Blazor Server.

user_18892670

If it's purely computational then why not use a WASM language (e.g. Rust) and just invoke it from JavaScript? As Josef pointed out you could also use server side Blazor or simply invoke a web service end point.

user_140831390

It may not be fair to compare a program running in a Browser against a program running natively in OS. I rather compare Blazor against JavaScript as they both run on Browsers. The advantage of a program that can run in Browsers is that it can run in most devices, from PC to most mobiles. Besides, it is in a form of MSIL, which is harder to reverse engineer than JavaScript. However, there is a price to pay, which is performance (MSIL in Mono -> WASM -> Native).

user_148444240
Related