Check out my courses: https://nickchapsas.com
Become a Patreon and get source code access: https://www.patreon.com/nickchapsas
Hello everybody I’m Nick and in this video I will talk about the different dictionary types in C# and also the hashtable and how we can use them in different scenarios. I will also talk about one of the most common pitfalls that I’ve personally have fallen into unknowingly.
Don’t forget to comment, like and subscribe 🙂
Follow me on GitHub: http://bit.ly/ChapsasGitHub
Follow me on Twitter: http://bit.ly/ChapsasTwitter
Connect on LinkedIn: http://bit.ly/ChapsasLinkedIn
Keep coding merch: https://keepcoding.shop
For the record, whether the ImmutableDictionary is smart about allocations during its Add/Update/Remove operations doesn't really matter to me since I haven't met a single person that was aware of its underlying data structure. I personally used to choose an ImmutableDictionary because all I want is to return a dictionary that you can't change its values in any way, so I can't get behind a data structure that is smart about how it can be changed into a new datastructure efficiently when that's not the usecase I wanted anyway. Getting a value is O(log n) and that's all that matters to me. Of course this is just me and it's just one usecase but it looks like I much rather go with a ReadOnlyDictionary for that specific usercase.
This also has to do with C# not being an immutability first language. When ImmutableDictionary is an AVL tree and ReadOnlyDictionary is a hash table, but then the "readonly" keyword is used to create immutable elements in your code, then you know that naming is kinda inconcistent and it leaves a lot room for assumptions.
Interesting that your benchmarks showsDictionary with lock faster than a ConcurrentDictionary…. I wonder why.
Oh, be careful with this expectations about Big-O complexity estimations. Yes, something with O(n) complexity sounds great in theory. But this hides the actual cost of the static factors in the algorithm. I mean, what good is your great O(n) or O(n*log n) algorithm if there is some static cost for the calculation which is not expressed in the powers?
Not so long time ago, I worked on an application with kinda HUGE in-memory database. Consisting of many data lookup tables, typically having quite long strings as keys. In the end, for most cases SortedDictionary was used for performance reasons. Why? Because Dictionary or HashTable always need to run a hash function on the entire string. Lots of CPU cycles every time in order to do just that, please the collision handling afterwards within the hash table storage. On the other hand, if the typical pattern for the contents of your keys indicates that they are very dispersed, then a tree-based structure (AVL or RedBlack or whatever is used by SortedDictionary ATM) can make the decision to navigate in the tree after reading only the first bytes of the string contents.
When I saw all those immutable classes I was so happy I started to use them everywhere. Then I found out about the implementation and got soooo sad. Now I don't use them anywhere and simply use the good IReadOnly interfaces. Done. If the caller dares to cast those instances, that's their problem. LOL
Dictionary in C#.NET Explained with Examples
Dictionary in C#.NET Explained | Multiple Examples | Simple logic | English | TEK TUBER | TT
I wish C# supported the 'const' keyword the way C++ does. This would make all these weird "…AsReadOnly…()" methods and excess code required to make things readonly. Don't want something to be mutable outside of a class? Declare it const.
I remember when .net 1 came out. That was ages ago. But I've only worked professionally with .net 2 and above.
Anyways I never heard of this immutable dictionary. Now I know that it has a very specific use case…when you need an avl tree.
So never use ImmutableDictionary, what would be there use case if it performs worse all the time? What about ReadOnlyDictionary? Say I pre-initialize a Dictionary that from then will never change. What might be the best option to use? I am surprised that the Get operation (dict[key]?) is so slow for it, I thought it would be faster. Or was that something else? I have to to join the Discord…
that is very interesting, I guess because the ImmutableDictionary have to make copies of itself using an AVLTree is better with the memory because in a hash Table you have to allocate space even for the items that has not been added to the Dictionary I mean is not that much considering it is a pointer space so basically 64 bits in 64 systems for every item between the last computed hash and the new computed hash, so Immutable may be more memory efficient(I mean one instance will take less space than the equivalent instance of a dictionary)
I thought that the ConcurrentDictionary.AddOrUpate did not grab a lock.
How did you drill down to the concurrent dictionary code?
please add subtitle
"420 is always a random number"
never understood immutable objects. If you dont want things to change, dont change them
if anything gets reused and distributed over such a large space that you cannot guarantee it, you need to modularize better
in the end all you should offer are some safe objects or an api that cannot be "messed up" easily from the outside
many languages have ways to "hack" immutable objects and change them anyway and at that point a mere "this property is not meant to be changed" warning is enough
Caption not available in your videos plz add
I've recently discovered the HybridDictionary
So really there's only two Dictionary types.
Dictionary and ConcurrentDictionary.
Hashtable is obsolete. Dictionary<T, object> does the exact same thing.
ImmutableDictionary is very niche. The chances are that you are better off either:
– Using const/readonly fields/properties.
– Initialise a ReadOnlyDictionary from a JSON (or similar) file.
If you haven’t already, would you please create a video about thread safety? It is something one doesn’t need to care about most of the times but a very critical topic.
Wait, so I shouldn't be using Hashmap?
Hi, I love your videos. Why only some videos allow translation automatically?
SortedDictionary should be here too. The word "dictionary" and the hash table data structure were synonyms to me for a long time too until I learned that "dictionary" is just an abstract type that supports storing and getting value by key with many possible implementations e.g. hash tables and BSTs (I learned it from Skiena's book).
It's also interesting how the naming is done in other languages. In c++ standard library, for example, dictionaries are named "maps", and the type name doesn't specify the underlying data structure, but rather the fact if it's ordered or not, just like in .NET:
Dictionary<K,V> <-> std::unordered_map (hash table).
SortedDictionary<K,V> <-> std::map (red-black tree).
While in java they decided to make it more explicit: TreeMap<K,V> and HashMap<K,V> (both implement Map interface though).
Also, in .NET there's also OrderedDictionary (not to be confused with SortedDictionary :=) ).
Thanks for great videos… do you have any comments or measurements for SortedConcurrentDictionary?
I have to remember to never use the dictionary type I never knew existed. Done
Sounds like you got the issue narrowed down from A-Z
How do you make it so that you can access the source of .NET libraries straight from your IDE?
Dictionary has an O(n) for the add, and O(1) for the other operations.
Thanks but to be honest I don't think you did the title justice – I was expecting a discussion of real world use cases and the correct choice of dictionary for each, with the tradeoffs of each choice.
69 random age haha
“Hello, *mumble mumble intro*, today..”
Thanks for this great video.
I like that they are to the point, not tiring and teaching us something.
Keep up with great work you doing.