We are using XamDataGrid to display collection of items , we use a custom collection of ours as the backing data source. It currently implements IBindingList (and there by implements ListChanged event. When we bind this collection to our grid it works fine.
We recently ran into few complications recently when items were removed /added to collection during a short snap (ex., 8k items removed from one collection and added to another) , this resulted in performance issues. When we profiled , it indicated to - listChanged being raised per item being added /removed was resulting the in full task of addition/removal one at a time which is not optimal.
* If our collection implements INotifyCollectionChanged (there by raising updates with multiple items rahter than single) - would XamDataGrid use this interface to bind instead of binding it as a BindingList ? (i.e., does not bother with list changed events and lists to collectionChangedEvents , reason we can't remove IBindingList is preserve backward compatibility)
* If above is not possible - is there a way we can indicate to XamDataGrid that we intend to make bulk changes and optimize for that (dont try to recycle every addtion but rather wait for entire batch to complete.)
Would ideally prefer 1 rather than 2 even if it involves us making changes in how we configure our grid.
Hi Rama,
I have been looking into your post and the INotifyPropertyChanged interface is usually used for notification that a property value has changed. It provides a ‘PropertyChanged’ event which occurs when a property value changes. I believe that the ‘ListChanged’ event of the IBindingList interface is more suitable if you would like to detect the changes in you underlying data collection.
Could you please explain in more details what exactly is your issue with our XamDataGrid when removing 4000 data items from your data source?
Looking forward hearing from you.
Issue we see is a huge spike in objects allocation , these are propertychangedeventargs objects (one foreach item) , records (dataGrid) and other objects that are associated with collection changed.
These are not something we don't notice for single item change , just that when there is a huge collection update it causes massive memory pressure.
* we are seeing a significant uptick in time spent in Gen0 , Gen1 GC.
* significant uptick objects getting promoted to Gen2.
* If we force a garbage collection memory is back to normal but till the time a full GC is triggered UI ends being sluggish.
Visually as well we can see items getting removed one at a time and can notice the delay.
Hello Rama,
I am just checking if you require any further assistance on the matter.
I was looking into your scenario and in case you are implementing BindingList then you could control when/how to raise notifications. The IBindingList.ListChanged event can be raised with a ListChangedEventArgs where the ListChangeType is Reset. If you use BindingList<T>, you could derive from it, add the necessary methods which would manipulate the protected Items property and then call the protected on OnListChanged with a new ListChangedEventArgs(ListChangeType.Reset, -1, -1).
Let me know, if you need any further assistance on this matter.