Datagrid performance problems for customized rows

[Paulus Selin]

We are developing a view that needs to display automatically updated data. View is expected to be able to handle several hundred rows, of which about 100-200 could be changed per second. We would expect UI to be responsive when new rows are added cells of existing rows are changed. We would expect it also to work responsively when user is scrolling the content.

We have tested that use case works pretty well if we don't use any customization and text only fields. We are using following features that we have found slowing down the datagrid considerably:

• Checkbox column: This we have tackled by not showing the column while data changes. While this is inconvenient, we can live with it
• QueryRowHeight: Default row height was ok for us. We have registered QueryRowHeight with following calculation: e.Height = dataGrid.GetRowHeight(e.RowIndex) -10
  
• QueryRowStyle: We wanted to have green background for selected rows 

We are currently using Xamarin Forms 4.2 (UWP) and Datagrid version 17.3.0.19. This use case is relevant on UWP version of our multiplatform Forms client.

We have tested also replacing our UI with example Page copied from SfDatagrid documentation and noticed that it also slows down considerably with QueryRowHeight and QueryRowStyle enabled.

We would like to know if there is anything we can do to have better responsivity, or if it would be possible to improve performance of SfDataGrid when these customizations are enabled.

Currently we have tried optimizing the UI updates (both row adds and row content updates) to happen in batches as much as possible. While this helps UI not to completely freeze, it also makes UI to feel quite flow compared to competing platforms (meaning totally different platform on same PC like standard Microsoft WPF datagrid).

[Karthikraja Kalaimani]

Hi Paulus,

The performance issue causes due to QueryRowHeight enabled in SfDataGrid. To improve the performance of SfDataGrid set the EnableCaching as true on QueryRowHeight. For more details please refer to the below code snippet.

Code snippet :

 

  private void DataGrid_QueryRowHeight(object sender, QueryRowHeightEventArgs e) 

  {
            e.Height = dataGrid.GetRowHeight(e.RowIndex) - 10;
            e.EnableCaching = true; 

            e.Handled = true;         
  }

 

Regards,
Karthik Raja 

[Paulus Selin]

Thanks for your answer,

I experienced having this one extra line "e.EnabledCaching = true;" in the Height query.

I found out that it seems to only help squite small amount: there seems to be only small difference on how often the QueryRowHeight is called. I have simple test case that adds batch of rows every 100ms. In my latest tests first ~1000 rows 150 / sec and then another ~1000 rows 40 / sec (150/sec is too much for it, 40/sec is not).

• Total 2002 rows in the OrderInfoRepository.OrderInfoCollection (OrderInfoRepository copied from SF examples)
• When inserting to start of collection, there is no difference on QueryRowHeight counts with or without e.EnabledCaching: total 55679 times.
• When inserting to end of collection, there is about 10% difference: 
•    e.EnabledCaching = false -> 59680 
•    e.EnabledCaching = true -> 55733

I implemented my own cache based on rowIndex. While QueryRowHeight is still called quite a lot, this results calling less dataGrid.GetRowHeight and gives me a little better performance. (Also there is risk that I don't clear my own cache always when it should -> this is only temporary solution)

Is there maybe any means for OnQueryRowStyle caching? We still only have very bad-looking (slow-looking) workaround for that, and it seems to cause lots of performance loss.

When adding 2002 rows and modifying some rows total 3500 times, we have around 188000 row style queries before any custom style is even needed..

[Karthikraja Kalaimani]

Hi Paulus,

We suspect that the performance losses due to calling GetRowHeight() method from QueryRowHeight event. Also we suspect that in your cases 1000 records can be similar height, so in this case no need to get the height from GetRowHeight() method each time and you can store that calculated value from GetRowHeight() method and  then apply that height to e.RowHeight instead of getting each time from GetRowHeight() method. So, this could improve the performance.

Regarding “QueryStyle”

You can set the SelectionBackgroundColor by writing style for DataGridStyle instead of QueryStyle event. So, this could improve the performance.

Please refer to the below UG to know about GridSytle.

UG link : https://help.syncfusion.com/xamarin/datagrid/styles

Regards,
Karthik Raja 

[Paulus Selin]

Thanks for your reply.

Unfortunately there are height differences for the rows, so we need to use own workarounds (own caching) for GetRowHeight. However, we often have a single text field which might grow to require several rows, so we maybe investigate possibility of accessing the related field and using that info for better caching.

We will investigate possibility of using SelectionBackgroundColor. Now when I think it, we often can live with one alternative color -> This might be good enough workaround for our QueryStyle performance issues.

[Karthikraja Kalaimani]

Hi Paulus,

We will wait hear from you.

Regards,
Karthik Raja

[Paulus Selin]

Hi,

I was finally able to test the workaround using the selection mechanism and the related background color.

Seems that performance for our current use case is OK with this workaround. We also found a performing way to use several colors for our near future use cases.

I must say that this is not exactly optimal solution due to its nature of miss-using a feature and needing complex approach to be usable as a generic component in our software.

But anyway, the main issue is now solved. Thanks for your help.

[Karthikraja Kalaimani]

 

Hi Paulus,

Thanks for the update. We glad to know that your requirement has been achieved. Please let us know if you have any further queries on this. We are happy to help you.

Regards,
Karthik Raja