4

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

Anthares
  • 1,041
  • 1
  • 13
  • 30
  • You can create a class that derives from ObservableCollection so that notifications are only done after the end of a batch of updates: http://stackoverflow.com/questions/9853064/what-i-want-to-do-is-freezablecollection-addrangecollectiontoadd/9853767#9853767 – Bob Horn Jul 23 '12 at 14:49
  • @Bob: we have already tried to suppress the OnCollectionChanged until the completion of the batch that adds and removes data. Unfortunately that does seem to help in our scenario because of the huge amount of points that have to be displayed. – Anthares Jul 23 '12 at 15:20
  • What about looking into Reactive Extensions? [Here's](http://blog.petegoo.com/index.php/2011/11/22/building-an-auto-complete-control-with-reactive-extensions-rx/) an example using Rx with M-V-VM (and thus, an ObservableCollection), and more specifically the "ObserveOn" method – Thelonias Jul 23 '12 at 15:24
  • @Ryan: thanks for your suggestion. We are digging it as it sounds really interesting. However I am not sure it could be a viable solution, as it relies on an external library. – Anthares Jul 23 '12 at 16:24
  • @GianlucaColucci Yea, at least it's still a Microsoft library... maintained by msft. But I understand the hesitation. – Thelonias Jul 23 '12 at 17:12

2 Answers2

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.

Graham Murray
  • 252
  • 1
  • 8
  • @GianlucaColucci I believe I have received a sample related to your issue. The main issues where *Implementation of AddRange and RemoveRange were inefficient. Repeated operations on a collection aren't as fast as, say, calling AddRange on a List. Suggest using List instead and implement INotifyCollectionChanged manually for AddTail and RemoveHead. *If you are only changing a small number of elements in the collection it is better to send Add or Remove with the list of changed items and the starting index rather than sending Reset. – Graham Murray Jul 25 '12 at 17:47
  • thank you very much for the assistance. We've followed your advice, we've made few additional changes (such as implementing the method "clear") and everything runs smoothly now! – Anthares Jul 30 '12 at 14:04
0

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.

Rachel
  • 130,264
  • 66
  • 304
  • 490
  • Thanks for your help! My bad, I missed to provide some code snippet and additional information about the methodologies that we have already adopted and currently using. I've updated the original post with some further details. As you can see, the solutions you are suggesting are quite similar to ours. Do you have any idea about how we can improve the performance of the data plotting? Thanks! – Anthares Jul 24 '12 at 09:12