I am seeing memory consumption skyrocket after upgrading from 20.3.0. .47 to 188.8.131.52.
When the dataset is large and filtering of the dropdowns occurs, it may take a few seconds to render them. Changing the dropdown or datepickers triggers a rerender of the data in the dropdowns. If i interact with the dropdowns or datepickers during the render period, the app can get into a state where memory in the w3wp IIS process grows indefinitely until it consumes all the available memory on the server.
<EditForm Model="@ReportRequest" OnValidSubmit="@GenerateReportAsync">
<SfDatePicker TValue="DateTime?" @bind-Value='@EndDate' Min='@EndMinDate' Max='@MaxDate'>
<DatePickerEvents TValue="DateTime?" ValueChange="ReloadDropdownsAsync"></DatePickerEvents>
<SfMultiSelect Width="500" Mode="VisualMode.CheckBox" TValue="int" TItem="SenderDomainModel" DataSource="@SenderDomainList"
@bind-Value="SelectedSenderDomainIds" AllowFiltering="true" ShowClearButton="false" ShowSelectAll=true SelectAllText="Select All" UnSelectAllText="Unselect All">
<MultiSelectEvents TItem="SenderDomainModel" TValue="int" ValueChange="ReloadDropdownsAsync" />
<MultiSelectFieldSettings Text="SenderDomain" Value="SenderDomainId"></MultiSelectFieldSettings>
SenderDomainModel sd = SenderDomainContext as SenderDomainModel;
When loading the large data to the component you can use the virtualization feature to resolve the memory conception issue.
To know more about the virtualization feature, refer to the below online demo and documentation below.
Documentation link: https://blazor.syncfusion.com/documentation/multiselect-dropdown/virtualization
Sorry but I dont see how this would stop the memory consumption, the data i am rendering is not that much, maybe 50 rows. It is filtered before rendering.
Hakop, our component does not replicate the performance problem when the 50 data are bound to the multiselect component. Additionally, the component data source loading time may affect performance when loading huge amounts of data, so we only offer the virtualization feature to address that performance loss. To validate that the performance issue is being caused by our multiselect component, check the performance issue with the multiselect component once more by commenting and uncommenting the component rendering code in your application. We'll validate and update the precise answer as soon as we can be based on your update.
I will try this, but rolling back to the prior version has already shown not to have the mem leak. I think it has to do with the user interaction with the form before the render is complete. I may have to spend more time to create a sample app to recreate this problem so you can see.