问题
My team and I are developing a WPF application that displays several concurrent XamDataChart controls (by Infragistics). Each chart is bound to a different ObservableCollection that can contain up to 2 million points. For each chart, a DispatcherTimer periodically retrieves new items (up to 1000 every 100 ms) that are to be appended to the collection. Every time new items come, they are added to the "tail" of a collection and the same amount is removed from the "head", so that the amount of items in the collection remains constant across time.
The problem we are facing is that the add/remove operations are freezing the GUI, because the collection can only be modified by the main thread. We have tried many approaches (BackgroundWorker, Application.Current.Dispatcher with DispatcherPriority.Background, Task.Factory, etc.) but none of them seems to solve the problem and the GUI keeps freezing.
Could you please advise us on the best approach for handing large amount of bound data while keeping the GUI responsive?
UPDATEs:
1) As indicated in my comment below, we have already tried to add and remove items while suppressing the OnCollectionChanged. Even if it seems to have effect with a small amount of data, in our scenario the advantages of this solution are really not observable.
2) Data are prepared and collected in a separate thread. This is a long-running operation, yet no slowness or unresponsiveness is evident. The application freezes when data are passed on to the chart component for rendering.
3) Here are the methods that generate data (in a separate thread) and display data on the UI:
private void GenerateDataButtonClick(object sender, RoutedEventArgs e)
{
Task<List<RealTimeDataPoint>> task = Task.Factory.StartNew(() => this.RealTimeDataPointGenerator.GenerateData(2000000));
Application.Current.Dispatcher.BeginInvoke(DispatcherPriority.Background, new Action(() => { this.DataPoints.Clear();
this.DataPoints.AddRange(task.Result);
if (!this.StartDataFeedButton.IsEnabled)
this.StartDataFeedButton.IsEnabled = true;
}));
}
public void DispatcherTimerTick(object sender, EventArgs e)
{
Task<List<RealTimeDataPoint>> task = Task.Factory.StartNew(() => this.RealTimeDataPointGenerator.GenerateData(1000));
Application.Current.Dispatcher.BeginInvoke(DispatcherPriority.Background, new Action(() => { this.DataPoints.RemoveRange(0, task.Result.Count); this.DataPoints.AddRange(task.Result); }));
}
Thanks in advance, Gianluca
回答1:
Its difficult to know the correct suggestion without knowing more about your scenario, so I'd recommend posting a sample to the Infragistics forums and asking for assistance, if you have not already done so, and if you have, please respond with a link to the post, and I'll take a look at it.
If you are updating many many points at once as separate operations it can be helpful to make your collection raise just one event rather than each individual event. For example, if you were updating the entire contents of the collection by calling Add repeatedly, it would be best to send one Reset event, rather than all the individual events. But it seems as if you are already calling AddRange, which I believe only sends one notification to the chart.
If you have just two series and are only updating them once every 100ms, I don't believe this should be causing UI freezing, but if you have many separate series that you are updating the data for individually with separate dispatcher interactions you will actually cause many more refreshes to the chart, than perhaps you intend.
The chart will batch up modifications and limit the number of refreshes, but it does this using the dispatcher, so if you have 15 different series that you are updating on different intervals, and all as separate dispatcher thunks then you are going to cause many more updates to the chart than if you throttled the number of updates by updating multiple series data sources in the same dispatcher thunk.
Additionally, if you are using the CategoryDateTimeXAxis, in your above code, you are likely hitting the limitation that it currently sorts the date column upon modification, which will murder your performance at that scale. In this instance, I'd recommend submitting a feature request for that axis type to support pre-sorted data.
If your data items support INotifyPropertyChanged, but you are not using this to notify the chart of value changes, it would be far better to use an item type that does not implement INotifyPropertyChanged. If you submit items that implements this interface the chart assumes it needs to subscribe to this in order to be notified of changes (that you may never be intending to make). This may not sound like a problem, but if you have 2 million records that you are updating with high frequency, that is a lot of event subscriptions to incur for no purpose.
The chart, to my knowledge, is far faster at retrieving values from a property binding than a string indexer, so make sure its a simple property, and also not a dotted property path in your MemberPath.
Hopefully this information will be useful to you. But it would be far easier to diagnose the issue with a runnable sample that provides all the context for what could be causing the issue.
回答2:
I've ran into this problem as well, where my code to obtain the data would often take a while, and it would freeze the UI while loading despite using DispatcherPriority.Background, and I couldn't use a background thread because WPF can't modify objects on the thread that didn't create the object.
What I ended up doing was actually using both methods: a Background thread to go get the data, and the Dispatcher to add the items to the ObservableCollection at DispatcherPriority.Background priority.
My code typically would look like this:
Task<List<MyClass>> task = Task.Factory.StartNew(() => GetData());
App.Current.Dispatcher.BeginInvoke(DispatcherPriority.Background,
new Action(delegate()
{
MyObservableCollection.AddRange(task.Result);
}));
Another option I've used in the past is await/async keywords from Async CTP Refresh
async void SomeMethod()
{
Task<List<MyClass>> task = Task.Factory.StartNew(() => GetData());
MyObservableCollection.AddRange(await task);
}
Note: The AddRange() method is part of a custom class that extends ObservableCollection, although you can probably build it as an Extension method as well.
public void AddRange(IEnumerable<T> collection)
{
foreach (var i in collection)
Items.Add(i);
OnCollectionChanged(new NotifyCollectionChangedEventArgs(NotifyCollectionChangedAction.Reset));
}
You could add a CollectionChanged call for each item added instead of a single Reset call at the end, but that will probably cause performance issues with the amount of data you're adding.
来源：https://stackoverflow.com/questions/11614396/add-remove-many-items-to-from-a-large-databound-observablecollection-without-fre