ObservableCollection数据绑定性能 [英] ObservableCollection Databinding performance

问题描述

我想知道为什么根据这个文章和可观察与WPF中的List<>集合相比，集合绑定的速度明显更快（20 ms，比1685ms，速度快800倍）。我观察了ObservableCollection的内部结构，它使用一个List作为它的存储集合对象（我使用反射器并在构造函数中看到这个）

I would like to know why according to this article and observable collection binds significantly faster(20 ms vs 1685ms, that's 800X faster) than a List<> collection in WPF. I looked at the internals of ObservableCollection and it uses a List as it's storage collection object(I used reflector and saw this in the constructor)

public Collection()
{
    this.items = new List<T>();
}

那么这里发生了什么？

推荐答案

该文章中的比较不在两个简单的绑定操作之间，这些测量是指将一个项目添加到WPF中的一种场景 ListBox ，它已经绑定到列表< T> 或 ObservableCollection< T> 。

The comparison in that article isn't between two simple binding operations, those measurements refer to a scenario in which you add a single item to a WPF ListBox that is already bound to either a List<T> or an ObservableCollection<T>.

正如笔者所说：

... CLR 列表< T> 对象
不会自动提高
收集更改的事件。为了
得到 ListBox 以获取
更改，您将不得不重新创建
您的员工列表并重新附加
到
ListBox 的 ItemsSource 属性。虽然这个解决方案是有效的，但是
引起了巨大的性能影响。
每次您将 ItemsSource
$ ListBox 重新分配给一个新对象时，
ListBox 首先抛出其以前的
项目并重新生成其整个列表。

...the CLR List<T> object does not automatically raise a collection changed event. In order to get the ListBox to pick up the changes, you would have to recreate your list of employees and re-attach it to the ItemsSource property of the ListBox. While this solution works, it introduces a huge performance impact. Each time you reassign the ItemsSource of ListBox to a new object, the ListBox first throws away its previous items and regenerates its entire list.

这解释了性能差异。即使 ObservableCollection< T> 由 List< T> 支持，它实现 INotifyCollectionChanged 接口，这使得所有这些额外的处理不必要。

This explains the performance difference. Even though ObservableCollection<T> is backed by a List<T>, it implements the INotifyCollectionChanged interface, which renders all that extra processing unnecessary.

这篇关于ObservableCollection数据绑定性能的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！