Collections and generics

● Data structure that stores multiple
objects (eg: a list of users)
● All objects of the same or common type
(eg: same Class, Interface, base class...)
● All are Enumerable (foreach, LINQ)
● namespace:
System.Collections.Generic
*System.Array
What are Collections?

● Ability to pass a Class as a parameter to
Another Class or Method.
Ex:
//Generic Collections of users (C#)
Queue<User> userQueue = new Queue<User>();
Stack<User> userStack = new Stack<User>();
List<User> userList = new List<User>();
//System.Array, Technically Not Generic but allowed
User[] users = new User[50];
What is Generics?

● Arrays
○Stored in Adjacent Memory Block
○Declared with Limited number of items
○Fast, Performance Efficient :)
○Low Flexibility :(
○Array, Stack, Queue, List, Dictionary, SortedList
● Multidimensional Linked List
○Stored and distributed arbitrarily in Memory
○Limited only by the amount of memory available
○Memory Efficient, High Flexibility :)
○Slow to Search :(
○LinkedList is a Linked List
○SortedDictionary uses a Binary Search Tree
Types of ‘Collections’ (All Platforms)

● Non-generic
○The ‘old’ type of collections
○each item in Collection is of type Object
○Must Cast (Box/Unbox) each item
○Windows Store BANNED!
○DO NOT USE!!! >:-(
● Generic
○Items of specific Type (using Generics)
○No Boxing/Unboxing or casting required
○Ok to use. Knock yourself out! :-)
Category of Collections (C#)

● O(1): same time allways (excelent!)
● O(logN): disproportionatly favorable (pretty good!)
● O(N): linear, proportional (ok, I guess...)
● O(NlogN):disproportionatly unfavorable (could be worse)
● O(N2): exponential (bad)
● O(N3): exponential (NOT GOOD AT ALL!!!)
before we begin... Big-O Summary!
Big-O Notation is a mathematical notation that measures the
performance scalability of an algorithm.
In context of Collections, it is usually Time vs Amount of Data.
Performance on Collections operations depends on Operation
and Type of Collection

● O(1): 1 ms
● O(logN): 20 ms
● O(N): 1,000,000 ms (16 min)
● O(NlogN): 20,000,000 ms (5 h 32 min)
● O(N2): 1,000,0002 ms (31.7 years!)
● O(N3): 1,000,0003 ms (31 MILLION YEARS!!!)
Big-O in Perspective (thought experiment)
Imagine we develop in an old computer where an operation to a
collection item cost 1 ms (one millisecond).
Imagine the old computer has an absurd amount of RAM and we
are operating on a Collection with 1,000,000 (1 million) records.

Generic Collection Types
ICollection
IList IDictionary Queue
DictionaryList
Stack
LinkedList
SortedList
System.Array
SortedDictionary
IEnumerable
ReadOnlyCollection
ObservableCollection
ImmutableList

IEnumerable<T>
● Iteration Behavior
● GetEnumerator()
● Enumerator allows you to navigate
Collection from Start to Finish
● LINQ
● If implemented, it is a Collection
● No Manipulation available
● Can’t count!

ICollection<T>
● Container Behavior
● Has Manipulation
● Count(), Add(), Remove(), Clear()
● is IEnumerable<T>

IList<T>
● Array Behavior
● Access using [index]
● More Manipulation: AddRange(),
RemoveRange(), Insert(), Sort()...
● is ICollection<T>

IDictionary<TKey, TValue>
● Map Behavior
● Access using [TKey]
● Manipulation! (Add, Remove, Clear…)
● is ICollection<KeyValuePair<TKey, TValue>>

● Stack<T>
● Queue<T>
● List<T>
● Dictionary<TKey, TValue>
● LinkedList<T>
● SortedList<T>
● SortedDictionary<TKey, TValue>
● ReadOnlyCollection<T>
● ObservableCollection<T>
● ImmutableList<T>
● *System.Array
Generic Collection Types
Note to Self: Remember
that there is code for
each of these...

● LIFO: Last In, First Out
● Push(item) to Add at the Top
● Pop() to Access/Remove from Top
● Eg: A ‘stack’ of Books
● Eg: Cars parked in a narrow
corridor
● No Index*
Stack<T> (Pila)

● FIFO: First In, First Out
● Enqueue(item) to Add/Push to Back
● Dequeue() to Access/Remove from Front
● Example: A line in a Bank
● No Index
Queue<T> (Cola)

● Queue and Stack are Lightning Fast!
● Are a reflection of the Limitations of
Digital Computing
● All Operations are O(1)*
● It’s called CallStack for a reason…
● It’s called MessageQueue for a reason...
● Use if you dont need Searching
Why use Queue<T> or Stack<T>?

● Has index for searching
● Reserves more Memory than it needs
● Read, Write, Add are O(1)*
● Insert and Remove are O(N)
● Use if you benefit from index access
List<T>

● Maps a TKey object with a TValue object
● Hashtable
● Reserves more Memory than it needs
● Read, Write, Add, Remove are O(1)*
● Use if you need to search objects
quickly using a data key. (id, code)
Dictionary<TKey, TValue>

● Capacity is the amount of Items a
collection can hold before having to
reallocate itself
● Capacity != Count
● List<T>, Queue<T>, Stack<T>,
Dictionary<TKey, TValue>
● When O(1) operation requires capacity
to change (Add), cost becomes O(N)
...About Capacity

● Only occupies the memory it needs
● Read, Write, Add, Remove is O(1)
● No Index, searching is O(N)
● Use if you need to access all items
● Avoid using if you need to search by
index or key
LinkedList<T>

● TValue is sorted automatically by TKey
● Read, Write are O(logN)
● Add, Remove are O(N)
● Less Memory Footprint than Alternative
● Slower than Alternative
SortedList<TKey, TValue>

● TValue is sorted automatically by TKey
● Self Balancing Binary Search Tree
● Read, Write, Add, Remove are O(logN)*
● Use if you need all items sorted
● Use if you want to search using Key
SortedDictionary<TKey, TValue>

Balanced vs Unbalanced Binary Search Tree
SortedDictionary<TKey, TValue>

● Read Only Wrapper
● Receives List<T> as parameter
● Source list cannot be modified through
wrapper
● Source list can be modified directly
● Modifications are reflected
● Not Thread-safe, Liability
● Use it when you want to prevent
modification under certain contexts.
ReadOnlyCollection<T>

● Has events for when elements in
collection change:
○CollectionChanged
● Think of the event as a Triggers (SQL)
● Use if you need to trigger events when
elements are added/removed or
properties changed
ObservableCollection<T>

● Cannot be Modified
● Thread-Safe
● Use if you want to access list in multiple
threads, but not write or change
ImmutableList<T>

● Primitive Type
● Succeded by List<T>
● Technically not Generic but Allowed
● Marginally better performance
● Can’t change size
● Use it if you really need maximum bare-metal
hardware performance
//Example of Array with 10 users
User[] users = new User[10];
//Example of TWO DIMENSIONAL Array with 10x10 users
User[][] users = new User[10][];
for (int i=0;i<10;i++) users[i] = new User[10];
What about System.Array?

● If you don’t know, then just use List<T>
● Only use LinkedList<T> if:
○need low memory footprint
○no need for index or key
○loop over all items
● As Hardware becomes more powerful,
List<T> becomes the better option
List<T> vs LinkedList<T>

● Use ImmutableList<T> if:
○Multithreading
● ReadOnlyCollection<T> is a wrapper, so
it has low memory footprint
● ImmutableList<T> is a copy, so it has a
high memory footprint
ReadOnlyCollection<T> vs
ImmutableList<T>

● Performance benefits only apply if using
Index (Array, List) or Key (Dictionary)
● Searching using LINQ on a Collection
defeats purpose of index/key
● LINQ search performance is O(N)
About Searching and LINQ

● Using LINQ over Sort has no
performance impact
● Sorting any type of Collections has a
cost of O(NlogN) (QuickSort, InsertSort,
MergeSort...)
About Sorting

● Default Collection types not Thread-Safe
(you can only use them in one thread)
● Thread-Safe version of Collections are:
○ConcurrentQueue (Queue)
○ConcurrentStack (Stack)
○ConcurrentDictionary (Dictionary)
○ConcurrentBag
○*System.Collections.Concurrent
Collections and Multithreading

● Immutables can also be used, but they
are read only
● Other Immutable Collections:
○ImmutableQueue (Queue)
○ImmutableStack (Stack)
○ImmutableList (List)
○ImmutableDictionary (Dictionary)
○*System.Collections.Immutable

● Finally, Worst Case, if you need to, you
can just use lock
void method(List<User> users) {
lock(users) {
//Do your multi threading stuff here
users.Add(new User { … });
}
}

● Remote communications and data
transmission performance: O(N)
● Make sure the Database does all the
hard work (filtering, sorting, joining)
● Think of Scalability
About Collections and Databases

● When exposing collections in WebAPI’s,
Microsoft recommends returning
interfaces rather than implementations.
○IEnumerable
○ICollection
○IList, IDictionary…
● Return Empty Collection
● Don’t return NULL
About Collections and Web API

● O(1): Most simple operations
● O(logN): Binary Searching
● O(N): Linear Searching, LINQ
● O(NlogN): Sorting
● O(N2): Nested loops
(Ex: for in a for)
Common Big-O Calculations

You are now a Collection expert!... sort of...
Questions?
...Aaaaaaaand… THAT’S IT!

Thank you!
Marco Hernandez
mhernandez@growthaccelerationpartners.com
Code:
https://github.com/marcohern/CollectionsAndGenerics

Collections and generics

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Collections and generics

Similaire à Collections and generics (20)

Plus de Miguel Angel Teheran Garcia

Plus de Miguel Angel Teheran Garcia (20)

Dernier

Dernier (20)

Collections and generics