Which dictionary to choose in C# and which one is dangerous

Software — 13/10/2022 · 32 Comments



Subscribe: http://bit.ly/ChapsasSub
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 🙂

Social Media:
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

#csharp #dotnet

32 Comments

  1. 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.

  3. 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.

  4. 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

  7. 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.

  9. 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.

  10. 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…

  11. 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)

  16. 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

  19. 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.

  20. 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.

  23. 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 :=) ).

  29. 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.

  32. Hi Nick
    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.

Leave a Reply

© 2023 53GB