Need Blazor Wasm Performance Improvement on CPU Intensive Calculations

[CincySteve]

I have a c# WinForms app that I have been converting to Blazor Wasm. It needs to perform a cpu-intensive calculation after most user inputs. The calculations entail repetitively (30-50 times) invoking a number of methods in a set of 25-35 objects depending on the scenario. Once started, the exact 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? Are there any ways to significantly reduce it? The objects that perform the calculations could easily be put in a class library.

[KieranDevvs]

You'd need to actually explain what you're trying to do before we can deduce what you're trying to achieve is possible.

[CincySteve]

@KieranDevvs I'm not certain what additional info you need. The app lets the user develop a personal finance model that contains one or more "building blocks" the user chooses and configures. Each time the user changes a building block (e.g. changing the gross income from a job or the forecasted return from an investment account), the app recalculates the model by invoking various methods in a set of building block objects, iterating over the number of years in the model. In the user model I used for the benchmark performance mention above, the model contains 40 building block instances across 13 different building block types.

Each building block puts the results it calculate into columns of a DataTable that they share. The recalculation performs no I/O or UI changes.

Not sure that helps. I'm afraid I don't want to share the code itself.

[KieranDevvs]

Well WinForms and Blazor have different component data models. Blazor uses component data binding to propagate events to and from the source (depending on how its configured). If you're binding properties to DOM components, then calculating and updating these properties, events have to be fired down to the component so that it can be re-rendered with the new data. Rendering is an expensive task. This is just one of the many differences between WinForms and Blazor.

In short, you cant and shouldn't compare the two technologies, they operate in very different ways and have different side effects.
Without a reproducible example of the issue you're having, everyone on here is going to struggle to diagnose why you're experiencing the performance hits.

Maybe try and create a blank solution and reproduce the issue with code that you would be willing to share. I would also advise you to read the guide lines on StackOverflow, on how to ask questions. While its not required to ask a community question, the rules serve as good indicators to get the best responses and eliminate back and forth questions to get to the root of the problem.

https://stackoverflow.com/help/how-to-ask

[CincySteve]

@KieranDevvs The calculations I need to run faster do not use data that is bound in any way. The WinForms and Blazor code that performs the calculations is literally the same. That’s the whole point, to reuse my existing code. Prior to posting this issue in GitHub, I posted questions about it on SO and the MS AspNetCore forums. I didn’t get any responses that clarified what I might expect. I will try to create a repro, but that may take some time due to some competing priorities. If this issue must be closed before I get to that, I’ll simply open a new issue. Thanks for your help.

[KieranDevvs]

I think you missed my point. I wasn't saying you were using data that was bound in any way, my point was to illustrate that the technologies are two completely different entities and its not as simple as, assuming the same code in one framework will correspond to be the same IL generated code as another framework.

Once you get a reproduceable repo, tag me in the link and ill take a look at what the issue may be.

[CincySteve]

@KieranDevvs If I've done things correctly, here's a reproduceable repo of the issue. The calculation code runs in 80ms within my WinForms app, but takes around 4000ms within the repo Blazor Wasm app (i.e. 50 times as long). This demo uses 2 Business Object classes to simulate the situation. My full app has ~25 BO classes with ~35 instances of a subset of those classes. Wait 4+ seconds after clicking the Calculate button. The app will display the elapsed time in ms.

[KieranDevvs]

Ok so I've taken a look and I managed to get your example down to 60-70ms relative to a console app running at 10ms. (its 6ish times slower but you have to remember WASM and Blazor are still new technologies with much more optimisations to be made to them, you're also running code in a sandbox environment which has additional logic such as memory violation checks etc).

I don't know the exact causes of all the slowdowns but the major parts seemed to be the data table and the decimal data type.
My guess is that DataTable is doing some form of dynamic type resolving for the column and row values and the sandbox doesn't like that (again, this is just my theory).

I managed to get the execution time down by replacing the data table implementation a nested list structure of one type and replaced the decimal value types with double.

using decimal seemed to double the execution time. I don't know what's going on there, my guess is that there's some runtime optimisations that the compiler would use that cant / isn't being used in the WASM sandbox.

I would open a ticket in the issue tracker regarding this as there does seem to be an issue outside of the expected sandbox overhead. Its also worth noting that the Blazor IL is currently being interpreted (which is probably what is causing the lack of optimisations for the issues above), we may see these issues being reduced in magnitude once AoT compilation is released in .NET 6 (or later, if it gets cut)

See #5466 for more details.

Edit: A potential temporary work around could also be for you to move some of the affecting code over to JS and use interop to gain the performance back. Yeah, it wont be as fast as it should be running under WASM but it should be usable none the less.

[CincySteve]

@KieranDevvs Just closing this issue out. Here's a post of the issue with the repro. I am being told that AOT will the fix in .Net6 which won't release until November, 2021.

Thanks for the help.