C# Collections - how to choose?

Cover image source

Collections

C# collections have plenty of options to use. When it comes to simple scenarios and small data handling any of these would work fine or at least give you the desired results. Things start to get messy when you have complex scenarios like multi-threading, huge chunks of data, indexing on collections, searching etc.

The Microsoft documentation on collections is a decent place to get started. One of the key things to note from this documentation is:

There are two main types of collections; generic collections and non-generic collections. Generic collections are type-safe at compile time. Because of this, generic collections typically offer better performance. Generic collections accept a type parameter when they are constructed and do not require that you cast to and from the Object type when you add or remove items from the collection.

This means that, in general, a generic collection should be used. The non generic collections will be stored as Object. This means that they will need casting when you are playing around with data. IMHO, I think this will play a very imp role when it comes to performance.

The MSDN link I added before has an excellent piece of advice that will help us in understanding which collection is to be chosen based on our requirement.

Collection	Generic Option	Non-generic Option	Thread-safe or immutable collection options
Store items as key/value pairs for quick look-up by key	Dictionary<TKey,TValue>	Hashtable	ConcurrentDictionary<TKey,TValue>, ReadOnlyDictionary<TKey,TValue>, ImmutableDictionary<TKey,TValue>
Access items by index	List<T>	Array, ArrayList	ImmutableList<T>, ImmutableArray
Use items first-in-first-out (FIFO)	Queue<T>	Queue	ConcurrentQueue<T>, ImmutableQueue<T>
Use data Last-In-First-Out (LIFO)	Stack<T>	Stack	ConcurrentStack<T>, ImmutableStack<T>
Access items sequentially	LinkedList<T>	No recommendation	No recommendation
Receive notifications when items are removed or added to the collection. (implements INotifyPropertyChanged and INotifyCollectionChanged)	ObservableCollection<T>	No recommendation	No recommendation
A sorted collection	SortedList<TKey,TValue>	SortedList	ImmutableSortedDictionary<TKey,TValue>, ImmutableSortedSet<T>
A set for mathematical functions	HashSet<T> ,SortedSet<T>	No recommendation	ImmutableHashSet<T>, ImmutableSortedSet<T>

Another important point that can act as a deciding factor is Algorithmic complexity of collections. Before you chose a collection, it is really important that the complexities are taken into account. This can sort out a lot of issues with respect to time complexities before hand.

In addition to this, David Fowler tweeted excellent points on Hashtable, Dictionary, ConcurrentDictionary, ImmutableDictionary

David Fowler 🇧🇧🇺🇸💉💉

@davidfowl

.NET has 4 built-in dictionary/map types:
- Hashtable
- Dictionary
- ConcurrentDictionary
- ImmutableDictionary

There’s no guidance on when to use what, mostly individual documentation on each implementation.

#dotnet

01:02 AM - 03 Oct 2021

• Dictionary
  

  

  David Fowler 🇧🇧🇺🇸💉💉

  @davidfowl

  

  Dictionary as immutable object - best read speed and lightweight to create but heavy update. Copy and modify on mutation e.g. new Dictionary(old).Add(key, value)

  01:02 AM - 03 Oct 2021

  

• HashTable, ImmutableDictionary
  

  

  David Fowler 🇧🇧🇺🇸💉💉

  @davidfowl

  

  Hastable - Good read speed (no lock required), sameish weight as dictionary but more expensive to mutate and no generics!
  
  ImmutableDictionary - Poorish read speed, no locking required but more allocations require to update than a dictionary.

  01:02 AM - 03 Oct 2021

  

• ConcurrentDictionary
  

  

  David Fowler 🇧🇧🇺🇸💉💉

  @davidfowl

  

  ConcurrentDictionary - Good read speed even in the face of concurrency, but it’s a heavyweight object to create and slower to update.
  
  Dictionary with lock - Poor read speed lightweight to create and “medium” update speed.

  01:02 AM - 03 Oct 2021

  

The motivation for all of this to put into once place, to keep things handy, came when I was working on one of the scenarios to select a collection. I ran into Scott Hanselman's blog, where he added a few pointers from David's tweet.

I would keep this handy for the next time I have to work on collections.