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

问题描述

我想知道为什么根据此文章和可观察的集合比WPF中的List<>集合显着更快地（20ms对比1685ms，这是800X更快）。我看了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 或者 ObservableCollection< T> 已经绑定到 List< T> c>。

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 属性。虽然这个解决方案工作，它
引入巨大的性能影响。
每次将一个 ListBox 的 ItemsSource
重新分配给一个新对象时，
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屋！