Blazorise
Blazorise copied to clipboard
Megabit
DataGrid high memory usage
Discussed in https://github.com/Megabit/Blazorise/discussions/3894
Originally posted by itsLollo1000 June 17, 2022 Hey @David-Moreira,
so we sort of have a problem with our DataGrid. We are using huge data collections and are rapidly reaching our process memery cap when using detailrows.
How is the memory and storing of detail rows handled? Currently when we open a DetialRow it adds arround 100mb of memory which is sort of not perfect but might has to happen. But when we close the exact same row again is also adds 100mb of memory.
Any information on that?
Kind regards Sebastian
This might be a data leak or something. I am not quite sure yet.
Here's a sample I created which i think shows something very intersting.
Commenting out the TriggerDetailRow call is on purpose.
Originally posted by @itsLollo1000 in https://github.com/Megabit/Blazorise/discussions/3894#discussioncomment-2971467
We keep state of each row internally, I'll take a look if there's anything that can be improved or is "faulty".
We keep state of each row internally, I'll take a look if there's anything that can be improved or is "faulty".
Would it be possible to disable the sate keeping? Because currently with out project it got unusable like this. We reach our memory limit within couple of rows.
Because even in the sample code it is possible to reach the date limit on the iis quite quickly.
In your example you are binding the DataGrid rows to TestItem, each of which contain a Bytes property containing an array of 20k+ bytes. 20k bytes * 10000 items = 400MB.
The DataGrid isn't what's hogging the memory, it's the objects you creating and binding to it.
Are you actually referencing those byte arrays to render something on the clients? Could you store them separately and only pull them in as needed?
In your example you are binding the DataGrid rows to TestItem, each of which contain a Bytes property containing an array of 20k+ bytes. 20k bytes * 10000 items = 400MB.
The DataGrid isn't what's hogging the memory, it's the objects you creating and binding to it.
Are you actually referencing those byte arrays to render something on the clients? Could you store them separately and only pull them in as needed?
Well the sample was just du create data that matches our amount of data. And yes sadly we have to create the object like this… but I still think there’s room for improvement on both ends.
I have been using the same data that we use in our project with Blazorise and MudBlazor. Comparing both grids today doing the same operations Blazorise used twice as much process memory than MudBlazor ones. Plus it is possible to reduce process memory when calling GC.Collect() after each time closing a DetailRow and leaving the page with the DataGrid.
Further more what I have noticed is that each time loading the grid takes a lot more memory in Blazorise than in MudBlazor. It seems to look like Blazorise always sort of „loads“(our data is already locally stored and loaded) something and uses memory whereas MudBlazor only loads excessively once.
Finally one thing I have noticed when having such big data, filtering also uses a lot process memory. To discuss this a bit more: filtering is set to only filter after enter is pressed. But already while typing each letter sort of gets filtered by the grid and cause process memory to rise. This last example could also be caused from our side with custom filtering but I think it is still worth noting.