Hello,
Is there any performance improvement between v15 and v18 (or 19) in handling bound scenario? Namely update/insert/remove records in underlying ObservableCollection. We maintain about 200K records collection and it seems max out UI thread while executing IG and .NET code, IG being the biggest CPU consumer. Couple profilers were utilized to trace the issue. We target .NET 4.6.1, x64. Thanks.
Hello Vlad,
The largest performance improvement that has been made to the XamDataGrid between versions 15 and 18/19 would be the change that was made in 2017.2 to use GlyphRuns instead of FormattedText in the SimpleTextBlock that is used within the cells, essentially making the rendering of cells in the XamDataGrid much faster. You can read about that here: https://www.infragistics.com/help/wpf/breaking-changes-in-2017-volume-2.
Outside of that, I don’t really see a reason that updating, inserting, and removal of records from the underlying ObservableCollection should be maxing out the UI thread, unless perhaps some of the performance-related “red-flags” are being raised, such as placing the XamDataGrid within a StackPanel, as this will essentially disable virtualization of the grid and kill its performance if you are putting 200K records inside. You can read about performance optimizations to the XamDataGrid here: https://www.infragistics.com/help/wpf/xamdata-performance-optimizations-overview.
Please let me know if you have any other questions or concerns on this matter.
Thanks for the quick answer. Where can I read about above mentioned StackPanel shortcomings?
I don’t believe we actually documented the “shortcomings” of the StackPanel, as they are actually completely expected due to the way that the StackPanel does its measurements. StackPanels in WPF will measure their children with an infinite height or width depending on the Orientation of the StackPanel. Doing this will disable the virtualization of the XamDataGrid by default if it is in a vertically oriented StackPanel, as the StackPanel will measure the grid with an infinite height, and as such all of the data record and cell presenters will be created rather than only creating them for the ones that are in view. As you might imagine, for 200,000 records, this would create a massive performance hit.