Rapide, performant et thread-safe collection observable

ObservableCollections élever les notifications pour chaque action effectuée sur eux. Tout d'abord ils n'ont pas de vrac d'ajouter ou de supprimer des appels, d'autre part ils ne sont pas thread-safe.

N'est-ce pas faire plus lent? Cant, nous avons une alternative plus rapide? Certains disent ICollectionView enroulé autour d'un ObservableCollection est rapide? Comment vrai est cette revendication.

Essayez cette collection qui prend soin de ce problème ainsi que d'autres multi-thread problèmes (même si tout faussé solution sera plus lent), qui aura inévitablement des cultures avec d'autres approches : codeproject.com/Articles/64936/...
Quand vous dites "thread-safe" voulez-vous dire que vous devez être en mesure de mettre à jour la collection à partir de plusieurs threads?

InformationsquelleAutor | 2011-10-07

72

ObservableCollection peut être rapide, si il veut pour. 🙂

Le code ci-dessous est un très bon exemple d'un thread-safe, plus rapide collection observable et vous pouvez l'étendre en outre à votre souhait.
```
using System.Collections.Specialized;
public class FastObservableCollection<T> : ObservableCollection<T>
{
private readonly object locker = new object();
///<summary>
///This private variable holds the flag to
///turn on and off the collection changed notification.
///</summary>
private bool suspendCollectionChangeNotification;
///<summary>
///Initializes a new instance of the FastObservableCollection class.
///</summary>
public FastObservableCollection()
: base()
{
this.suspendCollectionChangeNotification = false;
}
///<summary>
///This event is overriden CollectionChanged event of the observable collection.
///</summary>
public override event NotifyCollectionChangedEventHandler CollectionChanged;
///<summary>
///This method adds the given generic list of items
///as a range into current collection by casting them as type T.
///It then notifies once after all items are added.
///</summary>
///<param name="items">The source collection.</param>
public void AddItems(IList<T> items)
{
lock(locker)
{
this.SuspendCollectionChangeNotification();
foreach (var i in items)
{
InsertItem(Count, i);
}
this.NotifyChanges();
}
}
///<summary>
///Raises collection change event.
///</summary>
public void NotifyChanges()
{
this.ResumeCollectionChangeNotification();
var arg
= new NotifyCollectionChangedEventArgs
(NotifyCollectionChangedAction.Reset);
this.OnCollectionChanged(arg);
}
///<summary>
///This method removes the given generic list of items as a range
///into current collection by casting them as type T.
///It then notifies once after all items are removed.
///</summary>
///<param name="items">The source collection.</param>
public void RemoveItems(IList<T> items)
{
lock(locker)
{
this.SuspendCollectionChangeNotification();
foreach (var i in items)
{
Remove(i);
}
this.NotifyChanges();
}
}
///<summary>
///Resumes collection changed notification.
///</summary>
public void ResumeCollectionChangeNotification()
{
this.suspendCollectionChangeNotification = false;
}
///<summary>
///Suspends collection changed notification.
///</summary>
public void SuspendCollectionChangeNotification()
{
this.suspendCollectionChangeNotification = true;
}
///<summary>
///This collection changed event performs thread safe event raising.
///</summary>
///<param name="e">The event argument.</param>
protected override void OnCollectionChanged(NotifyCollectionChangedEventArgs e)
{
//Recommended is to avoid reentry 
//in collection changed event while collection
//is getting changed on other thread.
using (BlockReentrancy())
{
if (!this.suspendCollectionChangeNotification)
{
NotifyCollectionChangedEventHandler eventHandler = 
this.CollectionChanged;
if (eventHandler == null)
{
return;
}
//Walk thru invocation list.
Delegate[] delegates = eventHandler.GetInvocationList();
foreach
(NotifyCollectionChangedEventHandler handler in delegates)
{
//If the subscriber is a DispatcherObject and different thread.
DispatcherObject dispatcherObject
= handler.Target as DispatcherObject;
if (dispatcherObject != null
&& !dispatcherObject.CheckAccess())
{
//Invoke handler in the target dispatcher's thread... 
//asynchronously for better responsiveness.
dispatcherObject.Dispatcher.BeginInvoke
(DispatcherPriority.DataBind, handler, this, e);
}
else
{
//Execute handler as is.
handler(this, e);
}
}
}
}
}
}
```
Aussi ICollectionView qui se trouve au-dessus de la ObservableCollection activement au courant des changements et effectue des opérations de filtrage, de regroupement, de tri relativement rapide par rapport à toute autre source de la liste.

De nouveau observable collections ne peut pas être un parfait réponse plus rapide des données mises à jour, mais ils font leur travail assez bien.
- +1 pour la coutume de mise en œuvre. Mais Microsoft fait dire cela de n'importe où, à propos de la ICollectionView et ObservableCollection paire
- Je n'ai pas BlockReentrancy() ou DispatcherObject dans mon projet Silverlight, je suis en manque une référence ou est-ce WPF?
- Une autre question, si c'est thread-safe ET plus rapide, Microsoft, pourquoi ne pas le faire pour le standard ObservableCollection? Est-il un "coût" ce qui signifie qu'il n'est pas un best "par défaut" de la mise en œuvre?
- Définir le "plus rapide". Je ne vois pas comment il peut éventuellement être plus rapide pour augmenter la collecte changé avec remise lors de l'ajout de deux éléments, plutôt que de simplement l'ajout de ces deux éléments séparément. Si votre collection de 1000 éléments, l'INTERFACE utilisateur de s'actualiser pour tous les 1000 points au lieu de 2! Je pense qu'il est techniquement possible d'écrire un intelligent collection observable que les lots ensemble des mises à jour pour vous et soulève la collecte des événements de modification avec les bonnes actions, mais élever un RESET à chaque fois est . . . terrible.
- malheureusement, WPF écoute seulement à CollectionChanged sur Réinitialiser.
- Une bonne idée serait de définir une valeur de seuil, que la collection est notifié pour chaque élément ajouté, et l'appel de réinitialisation lorsque le seuil est dépassé.
- c'est plat incorrects. L'ajout d'un seul élément à une ObservableCollection soulève un seul CollectionChanged événement avec Action=Add. WPF serait terriblement inefficace si nécessaire une actualisation complète pour chaque collection de changement! Le po présente une collection avec une API et le nom qui est censé être rapide lorsqu'il est en fait va être beaucoup plus lent dans la grande majorité des cas d'utilisation.
- Je pense que vous êtes un peu à côté de la question. Le CollectionChanged de l'événement (et NotifyCollectionChangedEventArgs classe) déjà répondre à un événement unique pour informer de multiples ajouts/suppressions/peu importe, pourvu que ces modifications sont séquentielle au sein de la collection.
- J'ai mis en place un ObservableLinkedList, et sans Réinitialiser l'INTERFACE utilisateur n'est pas actualisé. Donc non, il n'est pas "plat" incorrect, c'est l'expérience.
- désolé, mais de mon point de stands. WPF ne fonctionne tout simplement beau avec ObservableCollection unique de l'événement avec l'action Ajouter. Vous devez avoir fait une erreur ailleurs, dans votre mise en œuvre. Vous pouvez très facilement le prouver par newing un OC<string>, de la fixation d'un gestionnaire d'événement, et l'ajout d'un élément. Vous obtenez un évènement unique de l'action Ajouter.
- Je parle de l'héritage de ObservableCollection ou de la composition-dessus d'elle. L'utilisation directe des œuvres (mais ce n'est pas vous qui déclenchent l'événement).
- n'avait aucun sens, désolé. WPF ne se soucie pas qui déclenche l'événement. Peut-être vous devriez poster votre mise en œuvre en est une autre question et je peux carillon là.
- Bien sûr ObservableCollection peut déclencher des événements à un seul article ajouté. Le problème de ce code résout (et pourquoi elle est appelée rapide) est l'ajout d'un grand nombre d'éléments de la collection. Si vous ajoutez beaucoup d'éléments à la fois, vous remarquerez énorme performance de baisser en raison de la grande quantité de NotifyCollectionChanged les événements déclenchés. C'est pourquoi il est préférable de le supprimer ajouter un événement, pour un temps, et de réinitialiser la collection lors de suffisamment d'éléments à ajouter.
- Babouin & Grégoire, désolé de ne pas être suivi de la progression sur ce fil. Mais Oui, comme Grégoire dit, le AddItems mise en œuvre est pratique pour un grand nombre d'éléments. Pour quelques centaines cela ne me surprend même pas la peine d'utiliser AddItems. Mais l'amélioration de la performance que j'obtiens lorsque j'ajoute multi-des milliers d'articles de la collection est importante. Vous pouvez tester vous-même. Une remise à zéro pour 1000 nouvellement ajouté des articles et 1000 notifications de faire beaucoup de différence. Aussi WPF élément conteneur réutilise virtualisé articles de toute façon. Donc même pour Reset appel, l'élément conteneur réutilise indi lignes.
- EXCELLENT morceau de code. A+
- DispatcherObject et prioty ne peut pas être utilisé par ma bibliothèque commune. Que puis-je faire à ce sujet?
- Quand vous dites "ne peut pas être utilisé par ma bibliothèque commune" que voulez-vous dire?
- C'est une solution à la AddRange problème, mais ce n'est certainement pas thread-safe. Essayez de liaison de cette collection sur l'interface utilisateur et ont quelques fois l'INTERFACE utilisateur et les threads d'arrière-plan de la mise à jour et vous allez vite en exceptions.
- Thx pour noter qu'à moi. J'ai ajouté le casier de l'objet en question. Voir la modifier. Merci encore une fois.
- Ce n'est certainement pas thread-safe. Même si vous avez ajouté locker autour de vos méthodes, les méthodes mises en œuvre dans le parent, c'est à dire ObservableCollection ne l'utilisez pas. Je ne pense pas que vous pouvez réellement créer de thread safe collection subclassing ObservableCollection.
- Que faire si le changement IList pour IEnumerable? Je pense que le rendement serait meilleur, par exemple lors de l'utilisation de Linq nous n'avons pas à appeler ToList() pour compiler.
InformationsquelleAutor WPF-it

Voici une compilation de quelques solutions que j'ai fait. L'idée de la collecte changé invokation prises à partir de la première réponse.

Semble aussi que le "Reset" de l'opération doit être synchrone avec le thread principal sinon des choses étranges se produisent à CollectionView et objet collectionviewsource.

Je pense que c'est parce que sur "Reset" gestionnaire essaie de lire la collection de contenu immédiatement et ils devraient être déjà en place.
Si vous n' "Reset" async et que juste ajouter quelques éléments aussi async que récemment ajouté des éléments pourraient être ajoutés à deux reprises.

public interface IObservableList<T> : IList<T>, INotifyCollectionChanged
{
}
public class ObservableList<T> : IObservableList<T>
{
private IList<T> collection = new List<T>();
public event NotifyCollectionChangedEventHandler CollectionChanged;
private ReaderWriterLock sync = new ReaderWriterLock();
protected virtual void OnCollectionChanged(NotifyCollectionChangedEventArgs args)
{
if (CollectionChanged == null)
return;
foreach (NotifyCollectionChangedEventHandler handler in CollectionChanged.GetInvocationList())
{
//If the subscriber is a DispatcherObject and different thread.
var dispatcherObject = handler.Target as DispatcherObject;
if (dispatcherObject != null && !dispatcherObject.CheckAccess())
{
if ( args.Action == NotifyCollectionChangedAction.Reset )
dispatcherObject.Dispatcher.Invoke
(DispatcherPriority.DataBind, handler, this, args);
else
//Invoke handler in the target dispatcher's thread... 
//asynchronously for better responsiveness.
dispatcherObject.Dispatcher.BeginInvoke
(DispatcherPriority.DataBind, handler, this, args);
}
else
{
//Execute handler as is.
handler(this, args);
}
}
}
public ObservableList()
{
}
public void Add(T item)
{
sync.AcquireWriterLock(Timeout.Infinite);
try
{
collection.Add(item);
OnCollectionChanged(
new NotifyCollectionChangedEventArgs(
NotifyCollectionChangedAction.Add, item));
}
finally
{
sync.ReleaseWriterLock();
}
}
public void Clear()
{
sync.AcquireWriterLock(Timeout.Infinite);
try
{
collection.Clear();
OnCollectionChanged(
new NotifyCollectionChangedEventArgs(
NotifyCollectionChangedAction.Reset));
}
finally
{
sync.ReleaseWriterLock();
}
}
public bool Contains(T item)
{
sync.AcquireReaderLock(Timeout.Infinite);
try
{
var result = collection.Contains(item);
return result;
}
finally
{
sync.ReleaseReaderLock();
}
}
public void CopyTo(T[] array, int arrayIndex)
{
sync.AcquireWriterLock(Timeout.Infinite);
try
{
collection.CopyTo(array, arrayIndex);
}
finally
{
sync.ReleaseWriterLock();
}
}
public int Count
{
get
{
sync.AcquireReaderLock(Timeout.Infinite);
try
{
return collection.Count;
}
finally
{
sync.ReleaseReaderLock();
}
}
}
public bool IsReadOnly
{
get { return collection.IsReadOnly; }
}
public bool Remove(T item)
{
sync.AcquireWriterLock(Timeout.Infinite);
try
{
var index = collection.IndexOf(item);
if (index == -1)
return false;
var result = collection.Remove(item);
if (result)
OnCollectionChanged(new NotifyCollectionChangedEventArgs(NotifyCollectionChangedAction.Remove, item, index));
return result;
}
finally
{
sync.ReleaseWriterLock();
}
}
public IEnumerator<T> GetEnumerator()
{
return collection.GetEnumerator();
}
System.Collections.IEnumerator System.Collections.IEnumerable.GetEnumerator()
{
return collection.GetEnumerator();
}
public int IndexOf(T item)
{
sync.AcquireReaderLock(Timeout.Infinite);
try
{
var result = collection.IndexOf(item);
return result;
}
finally
{
sync.ReleaseReaderLock();
}
}
public void Insert(int index, T item)
{
sync.AcquireWriterLock(Timeout.Infinite);
try
{
collection.Insert(index, item);
OnCollectionChanged(new NotifyCollectionChangedEventArgs(NotifyCollectionChangedAction.Add, item, index));
}
finally
{
sync.ReleaseWriterLock();
}
}
public void RemoveAt(int index)
{
sync.AcquireWriterLock(Timeout.Infinite);
try
{
if (collection.Count == 0 || collection.Count <= index)
return;
var item = collection[index];
collection.RemoveAt(index);
OnCollectionChanged(
new NotifyCollectionChangedEventArgs(
NotifyCollectionChangedAction.Remove, item, index));
}
finally
{
sync.ReleaseWriterLock();
}
}
public T this[int index]
{
get
{
sync.AcquireReaderLock(Timeout.Infinite);
try
{
var result = collection[index];
return result;
}
finally
{
sync.ReleaseReaderLock();
}
}
set
{
sync.AcquireWriterLock(Timeout.Infinite);
try
{
if (collection.Count == 0 || collection.Count <= index)
return;
var item = collection[index];
collection[index] = value;
OnCollectionChanged(
new NotifyCollectionChangedEventArgs(
NotifyCollectionChangedAction.Replace, value, item, index));
}
finally
{
sync.ReleaseWriterLock();
}
}
}
}

InformationsquelleAutor norekhov

2

Je ne peux pas ajouter des commentaires parce que je ne suis pas assez cool, mais le partage de cette question, j'ai couru en vaut probablement la peine de poster même si c'est pas vraiment une réponse. J'ai continué à obtenir un "Index était hors de portée" exception à l'aide de cette FastObservableCollection, en raison de la BeginInvoke. Apparemment, les changements notifiés peut être annulée avant que le gestionnaire est appelé, pour fixer ce j'ai passé la suite de la quatrième paramètre de la BeginInvoke appelé à partir de la OnCollectionChanged méthode (par opposition à l'utilisation de l'événement args un):
```
dispatcherObject.Dispatcher.BeginInvoke
(DispatcherPriority.DataBind, handler, this, new NotifyCollectionChangedEventArgs(NotifyCollectionChangedAction.Reset));
```
Au lieu de cela:
```
dispatcherObject.Dispatcher.BeginInvoke
(DispatcherPriority.DataBind, handler, this, e);
```
Ce fixe la "Index était hors de portée" de l'émission, j'ai été en cours d'exécution dans. Voici une explication plus détaillée /code snpipet: Où puis-je obtenir un thread-safe CollectionView?
- C'est parce que la FastObservableCollection n'est pas thread-safe. Les collections visés par ce lien ne sont pas, soit parce qu'ils ne fournissent pas TryXXX méthodes et à cause de cela, vous aurez toujours des questions telles que les exceptions lorsque vous essayez d'accéder à quelque chose qui n'est plus là parce que la vérification et les opérations ne sont pas atomiques. Essayez de codeproject.com/Articles/64936/...
InformationsquelleAutor jsirr13

Un exemple où est créé un synchronisé Observables liste:

newSeries = new XYChart.Series<>();
ObservableList<XYChart.Data<Number, Number>> listaSerie;
listaSerie = FXCollections.synchronizedObservableList(FXCollections.observableList(new ArrayList<XYChart.Data<Number, Number>>()));
newSeries.setData(listaSerie);

Veuillez remplir votre réponse.

InformationsquelleAutor Raul

Vous devez vous connecter pour publier un commentaire.