Bound ObservableCollection Update Performance

[Matt]

Hello,

I am having some trouble with the performance of the RadJumpList control when adding items to a collection that has already been bound to the control.  I have uploaded an example project that shows this problem here.

In this project, there are two buttons, Unbound and Bound.  Both buttons create an ObservableCollection of 100 objects randomly assigned to one of three headers, but the Bound button binds the collection to the RadJumpList before adding the items.

On my device, the unbound execution is very fast, under 1 second, but the bound execution takes about 8 seconds.  If you increase the number of items to 1000, the unbound execution still completes in under a second but the bound execution is much slower, taking over a minute to complete.

I noticed that removing the group descriptor results in much improved performance for the bound scenario.  The group descriptor is currently using string comparison, but I noticed no significant difference in execution time when using an integer instead of a string.

For comparison, I have not had this issue with a similarly configured LongListSelector from the SL toolkit.  The LongListSelector has a much different collection format though (a collection of collections rather than using a group descriptor), so that may be part of the reason.

Is there any way to improve the performance when adding items to a bound collection?

Thanks,
Matt

[Georgi]

Hi Matt,

Thank you for using RadControls for Windows Phone 7.

The problem here is that the entire data is re-evaluated when the collection is changed and there is a "Data operation" (that is one or more descriptors are added) within the underlying RadCollectionViewSource. We are aware of this problem and we have it scheduled for our first Service Pack - expected within several weeks.

There are however optimizations that may help in this scenario:

- Use the BeginDataUpdate() and  EndDataUpdate() methods to batch more than one change in the source collection. Using this approach will perform only one re-evaluation of data.

myJumpList.BeginDataUpdate();

// perform data change

myJumpList.EndDataUpdate();

- Use the Asynchronous Balance option:

myJumpList.IsAsyncBalanceEnabled = true;

We have plans to extend the asynchronous balance so that view-port items will be displayed at once and buffer items will be balanced asynchronously.

Let me know whether this information was helpful.

Best wishes,
Georgi
the Telerik team

[Georgi]

Hi Matt,

Thank you for using RadControls for Windows Phone 7.

The problem here is that the entire data is re-evaluated when the collection is changed and there is a "Data operation" (that is one or more descriptors are added) within the underlying RadCollectionViewSource. We are aware of this problem and we have it scheduled for our first Service Pack - expected within several weeks.

There are however optimizations that may help in this scenario:

- Use the BeginDataUpdate() and  EndDataUpdate() methods to batch more than one change in the source collection. Using this approach will perform only one re-evaluation of data.

myJumpList.BeginDataUpdate();

// perform data change

myJumpList.EndDataUpdate();

- Use the Asynchronous Balance option:

myJumpList.IsAsyncBalanceEnabled = true;

We have plans to extend the asynchronous balance so that view-port items will be displayed at once and buffer items will be balanced asynchronously.

Let me know whether this information was helpful.

Best wishes,
Georgi
the Telerik team

[Matt]

Hi Georgi,

Turning on the asynchronous balance option made a significant improvement in performance when modifying a bound collection.  Using the BeginDataUpdate/EndDataUpdate methods got the execution time down to about the same as the unbound method.

Thanks for the help,
Matt