Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.
  2. Dismiss Notice

Question Entering Dictionary Key-value pairs

Discussion in 'Scripting' started by sigma-z-1980, Sep 4, 2023.

  1. sigma-z-1980

    sigma-z-1980

    Joined:
    Oct 27, 2015
    Posts:
    5
    Is there a general rule whether for a general-type dictionary
    Dict<TypeA, TypeB> dict = new Dict<TypeA, TypeB>();
    entering

    Code (CSharp):
    1. dict[value1]=value2
    is preferred to

    Code (CSharp):
    1. dict.Add(value1, value2)
    Assuming the list of values is arbitrarily long.
     
  2. Kurt-Dekker

    Kurt-Dekker

    Joined:
    Mar 16, 2013
    Posts:
    36,563
    Don't think it would make any difference. The
    operator [
    (the "indexer" I think it is called?) version is likely just a property wrapper to call the
    .Add()
    method, or so I would imagine.

    EDIT: looks like Add will complain bitterly if the key already exists, so that's a substantial difference.
     
    Bunny83 likes this.
  3. sigma-z-1980

    sigma-z-1980

    Joined:
    Oct 27, 2015
    Posts:
    5
    Thanks. Would that be the only one though? Especially in terms of optimization/memory
     
  4. Kurt-Dekker

    Kurt-Dekker

    Joined:
    Mar 16, 2013
    Posts:
    36,563
    You can answer that yourself.

    DO NOT OPTIMIZE "JUST BECAUSE..." If you don't have a problem, DO NOT OPTIMIZE!

    If you DO have a problem, there is only ONE way to find out. Always start by using the profiler:

    Window -> Analysis -> Profiler

    Failure to use the profiler first means you're just guessing, making a mess of your code for no good reason.

    Not only that but performance on platform A will likely be completely different than platform B. Test on the platform(s) that you care about, and test to the extent that it is worth your effort, and no more.

    https://forum.unity.com/threads/is-...ng-square-roots-in-2021.1111063/#post-7148770

    Remember that optimized code is ALWAYS harder to work with and more brittle, making subsequent feature development difficult or impossible, or incurring massive technical debt on future development.

    Don't forget about the Frame Debugger either, available right near the Profiler in the menu system. Remember that you are gathering information at this stage. You cannot FIX until you FIND.

    Notes on optimizing UnityEngine.UI setups:

    https://forum.unity.com/threads/how...form-data-into-an-array.1134520/#post-7289413

    At a minimum you want to clearly understand what performance issues you are having:

    - running too slowly?
    - loading too slowly?
    - using too much runtime memory?
    - final bundle too large?
    - too much network traffic?
    - something else?

    If you are unable to engage the profiler, then your next solution is gross guessing changes, such as "reimport all textures as 32x32 tiny textures" or "replace some complex 3D objects with cubes/capsules" to try and figure out what is bogging you down.

    Each experiment you do may give you intel about what is causing the performance issue that you identified. More importantly let you eliminate candidates for optimization. For instance if you swap out your biggest textures with 32x32 stamps and you STILL have a problem, you may be able to eliminate textures as an issue and move onto something else.

    This sort of speculative optimization assumes you're properly using source control so it takes one click to revert to the way your project was before if there is no improvement, while carefully making notes about what you have tried and more importantly what results it has had.
     
  5. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    10,468
  6. dlorre

    dlorre

    Joined:
    Apr 12, 2020
    Posts:
    700
  7. lordofduct

    lordofduct

    Joined:
    Oct 3, 2011
    Posts:
    8,378
    There's no rule.

    They effectively do the same thing.

    The primary difference is that Add will throw an exception if an entry for that key already exists. Where as the indexer version will not.

    I personally use the indexer version myself in most scenarios because in most scenarios I want to do an add or replace, meaning I don't want the exception to throw.
     
    Ryiah likes this.
  8. halley

    halley

    Joined:
    Aug 26, 2013
    Posts:
    1,834
    Yeah, it's one of those strange quirks when Microsoft took their Java implementation and scrubbed away all the serial numbers when they were hauled into court, thus giving us C#.

    In Java, there is an explicit named method to put new values into a dictionary, replacing the existing value if a key exists or adding the key if it doesn't. Microsoft decided that C# should have operator overloading, and further, inexplicably, that the Item[] operator for dictionaries should behave differently from all explicit named methods. It's not just syntactic sugar, it's the only way to replace the existing value if a key exists.

    See, judge, C# is totally a whole new language we've been working on for a looooong time, and not just a recycled husk of hot property snagged while Sun and Oracle were distracted.
     
    Kurt-Dekker likes this.
  9. Bunny83

    Bunny83

    Joined:
    Oct 18, 2010
    Posts:
    3,495
    Note that MS actually has reference source up on the internet you can look at for most of the .NET framework. As you can see here both the setter of the indexer as well as the Add method both use the same method under the hood. However Add specifically throws an exception if the key already exists (since it's supposed to add the key and duplicates are not allowed) while the setter does not throw an exception. This is controlled by the "add" argument of the internal "Insert" method. So it's literally the same code, though the behaviour when facing duplicate keys differs.
     
    lordofduct, Kurt-Dekker and MelvMay like this.