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

问题描述

我想知道为什么根据本文章并观察集合显著快结合（ 20 ms和1685ms，那就是速度800X），比一个List<>集合在WPF。我看着的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>();
}

那么，什么是怎么回事？

So what's going on here?

推荐答案

这是文章中的比较是不是两个简单的绑定操作之间，这些测量是指在其中一个项目添加到WPF 列表框对已经绑定到一个列表< 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 属性。虽然这种解决方案的工作，它
引入了一个巨大的性能影响。
每次重新分配的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> 被支持的列表< 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屋！