[Blazor WebAssembly] Serious performance issues

[julienGrd]

Hello guys, I would like to discuss performance problems i met with my Blazor App.

It will be a very long text with a project example to illustrate this, so please read with attention before respond.

I rewrite since one year a silverlight app in blazor, and i notice since the begining some performance issues on some heavy views.
The behavior is really bad, its a completely browser freezing and nothing respond (not only the app, all the browser, the loading effects in css are also freeze).

On the worst case of my app (navigate to a really big view to another), this freeze can take 12 seconds which is not just not acceptable.

I recheck the way of my components react before open this issue (be sure my components no render too many times) and on my side there is no problem, they are renders only one time even with 10 seconds freeze.

I precise i have this behavior only in webassembly, my app work also on server side and on this mode, the app is really more faster and i don't have this "freeze" effect (for example the 12seconds freeze in webassembly are transform in 1 or 2 second but this time make sense considering the amount of data shown, and the browser not freeze).

So i try to create a sample project to understand whats the problem : blazor ? the way i use it ? other ?

You will find the sample here https://github.com/julienGrd/BlazorTest
This sample have 4 views, each view show the same data, 3 link showing a different table of 1000 lines, but by different ways.
The question is not to know if 1000 line in a table is a good idea because obviously is not but observe the performance between the different ways

• FetchData V1 : In this view i use a "advance" table component insipired but what i create on my app but really more simple. This component authorise the selection and reordering by clicking on the header. To make this possible, i had to play with CascadingValue to provide a way for my rows and my columns to communicate with the parent, the grid.
  At this time i want to say the way i do it is quite of ugly but it seem i can't do better at this time, there is some issues opened here wich speak about the problems we have to make a good and efficiency communication between components. For example provide a way in my Grid component to directy have a IEnumerable as a parameter.
  When i change Page on this view, i note on my laptop an average of 4 second freeze.

• FetchData V2 : Its the same than the V1 except i inject the parent with classic parameter and not cascadingParameter. I was thinking was the problem, it seem not, i observe the same performance (average of 4 second)

• FetchData Simple Table : In this View, I use a different component to render only a simple table without specific behavior. And the things become interesting. I notice changing Page take only 1 second on this View. So it seem it more the way blazor deal with my grid component the problem than the amont of data rendered.

• FetchDataJs : In this view i dont use at all blazor system but i do everything in js to see the "difference". I notice on this view an average of 1 second to change page which is close to the fetch data simple table.

So the question is : why the first two view take 4 second for changing page and the others only 1 second ? i put some console.writeline in the OnAfterRender of my components to be sure everything is rendered one time.

we can also notice something when browser freeze in the browser console : some webassembly Garbage collector log like this

L: GC_MAJOR_SWEEP: major size: 9440K in use: 19819K
L: GC_MAJOR: (LOS overflow) time 31.00ms, stw 31.02ms los size: 14256K in use: 11098K
L: GC_MINOR: (Nursery full) time 26.06ms, stw 26.10ms promoted 952K major size: 15920K in use: 14653K los size: 23392K in use: 20592K

Im not able to understand the value provided by this log, webassembly is a black box for me.
for example on my app when a 10 second freeze happen i have these values

L: GC_MAJOR_SWEEP: major size: 16688K in use: 34623K
L: GC_MAJOR: (LOS overflow) time 59.83ms, stw 59.98ms los size: 4240K in use: 2789K
L: GC_MINOR: (LOS overflow) time 0.81ms, stw 0.88ms promoted 0K major size: 16688K in use: 6798K los size: 4240K in use: 2789K

Thanks in advance for your help, for me it actually really a big deal because for now its a no go to put in production after one year of work.

I precise my app don't have table with 1000 rows but sometimes until 250, with 15 columns, and a content inside cell really complex, additionate with advance table scenario like grouping, filtering, resizing, etc. so my 10 seconds freeze are not really surprising if a 1000 row simple table put 4 seconds to show. It the actual behavior with the silverlight app and this last one can easily take 1000 rows like this without specific problems, so the company i work for will not accept answers like "there is too many data"

[javiercn]

@julienGrd thanks for contacting us.

We'll take a look at the issue in more depth and get back to you. One thing that comes to the top of my mind is that, (haven't looked at the app yet) is that it is likely a good idea for you to virtualize the list, meaning that you don't render the 1000 rows every time and that instead you only render the subset of rows that can confortable fit on the screen, and when the user scrolls in some way or performs a gesture with an arrow key, you load more data.

I can't tell for sure about the messages in the console since I'm not that familiar with the mono GC, but I would think that what you are observing are GC collections taking place on the Large Object heap (I guess mono calls it stack?) and that is going to cause some freezing.

I'm not sure if there is a way to configure the memory limits for the .NET Runtime, @SteveSandersonMS might now more about it, and that might palliate the problem, but it's only going to increase the upper bound.

The main issue to tackle there would be to understand why you are allocating so many large objects on the heap, which I think is causing the performance penalties. That also can explain why you are seeing a big difference between the client and the server. In the server case there is likely way more memory and also the server uses a difference GC and GC mode, which can explain why it's way faster, but ultimately, it comes down to the fact that there's always going to be a limit of rendered elements that is going to cause a slow-down in the app.

[julienGrd]

thanks for you reply @javiercn

Concerning the virtual scrollink i was thinking of that. However in my case the rows have dynamic height based on the content, wich make the thing really tricky to an efficient virtual scroll system (everything i see on internet was a fixed height row system). if you have some resources to achieve it i take it.

I can't tell for sure about the messages in the console since I'm not that familiar with the mono GC, but I would think that what you are observing are GC collections taking place on the Large Object heap (I guess mono calls it stack?) and that is going to cause some freezing.

Yeah it seem really related, each freeze superior at 2 second coincidate with this kind of logs messages

The main issue to tackle there would be to understand why you are allocating so many large objects on the heap, which I think is causing the performance penalties. That also can explain why you are seeing a big difference between the client and the server. In the server case there is likely way more memory and also the server uses a difference GC and GC mode, which can explain why it's way faster, but ultimately, it comes down to the fact that there's always going to be a limit of rendered elements that is going to cause a slow-down in the app.

Yes sure, for now i don't have the hand on the way the app present data, i just make the technical migration of an app where sometimes the table have 250 rows, i know its not recommanded, but the actual app work like that since years without problem.

Thats why i think you have to focus on my implementation 1 (Grid V1) and 3 (Simple Table) : both are made with blazor, both just render a table of 1000 rows. the first take 4 second, the other take 1 second. I have to understand why because if i can divide the execution time by 4 in my app, i win, the worst scenario will be 3 second (which can be acceptable considering the amount of data) and 98% of my app will be really fast.
But there is something in my implementation which make this grid 4x slower. Im sure its related the way the components are imbricated and communicate each others, but i make things like this to handle specific scenario and don't know if there is "better way".

So the goal is to find an implementation of my first component with keeping behavior of selection and Sorting but with the performance of implementation 3.

and it's not so easy.

[mlathan]

@julienGrd I can confirm your observations. Currently I'm also experimenting with a TableView which displays fixed height rows and variable widths columns. For this I have a container component, the TableView, which inside renders the grid cells in two for loops (rows, cols). Like @javiercn mentioned I already virtualized the scrolling, react on resizing and also use HTML Grid Layout in a clever way to minimize required HTML for table layout. I can have 1.000.000 rows with constant performance.

I tried different approaches for the cell rendering inside the TableView div (visible 40 x 13 = 520 cells):

1. RenderFragment with parameter (the data to show in the cell) as Delegate, which contains a Component. This is by far the slowest. Parameter binding in Blazor is very expensive because internally it is based on Type and String matching on properties. Component instancing also.

2. RenderFragment with parameter (the data to show in the cell) as Delegate, which contains HTML. Second slowest. My observation is, that it is expensive to transport the Parameter to the RenderFragment. Bit faster because no Component involved. But HTML wich is inspected by Blazor.

3. Directly render HTML in the for loops of the TableView. Third slowest. There is again overhead in that Blazor "looks at the" HTML elements inside the Razor environment. By "looks at" I mean it always flows through the RenderTreeBuilder which does caching and re-using of DOM elements and stuff.

4. Use StringBuilder to generate the whole set of grid HTML in a dedicated render method inside TabelView and hand this as MarkupString to the Razor code. Idea is to prevent Blazor from "looking" at the HTML elements. Fourth slowest ... and fastest approach. BUT you loose all the blazor comfort ... events @key etc.! With this approach I can have 50 fps on my machine while scrolling. The more characters you generate inside the StringBuilder the slower it gets.

... and yes I also got a lot of GC messages on the log. In a another issue, can't remeber which, a person asked whether the GC log messages are problematic. They are not. BUT like @javiercn said is an indication that we use Blazor mechanic in a way that pushes the WASM Blazor mechnic to its limits.

For this kind of stuff we definitely need AOT compilation for faster code execution. The current C# .Net Blazor WASM mechanic isn't able to re-render, with parameter setting, lots of Components many times a second.

[julienGrd]

@mlathan Is your virtualization system is something we can see somewhere (i speak about the source code) ? (i see you have fixed height row, which is not my case, but it can can be a good start).

I put this subject aside, I don't know how to make an efficient virtualization system with my dynamic height rows, and i don't understand how we can reach the limit of the system with a simple 250 rows table. The webassembly version is really slow, i hope AOT compilation will be a game-changing. I really hope don't have to manage all my grid in javascript, it will be a real disappointment for this technologie (which is amazing, for now)

[pranavkm]

I've written a draft for authoring performant Blazor applications as part of dotnet/AspNetCore.Docs#18277 (comment). It includes a sample for virtualization. Could you give that a try?

In addition, we're looking at continuing to invest in areas of 5.0 including,

• Supporting change detection for data types including complex data types. Tracked via Blazor change detection too liberal #13610
• AOT
• .NET WASM runtime, GC, and BCL improvements that should happen as part of the .NET 5 merge.

[julienGrd]

@pranavkm thanks for this code, its really a cool code I would not have done better.

I integrate in my test app : https://github.com/julienGrd/BlazorTest

You now have a new menu Fetch Data Virtualize where i use your virtualization system in my grid, the performance are really good, the ordering feature works well, selection too included keyboard navigation (except some scroll synchronisation with my selected items, i have to work on that).

Now i have to make it work with different height rows...

I will add more and more feature on the future, to see if we keep good performance

[SteveSandersonMS]

@julienGrd In case it's of interest to you, I've also proposed what I think is a better way of doing list virtualization that should perform better still and may avoid some of the scroll synchronization issues you've mentioned. Might be worth trying it out in your app: pranavkm/repro#2