Discussion: mutable SCG.Dictionary, lookup missing key, enumeration, and arm64 architecture results

[iamim]

1. Would you be willing to add the default Dictionary implementation to the benchmark suite? I understand that it's like comparing oranges to apples :) However, this is how it is: if immutable collection don't deliver you start looking into the mutable ones and Dictionary is the standard (at least that's how I'm thinking about it).
2. I see some other benchmarks testing a missing key lookup and key/value/KeyValuePair enumeration speed. Do you find these cases useful?
3. I could help running the results on arm64 (M1 Pro) to add the results. I just need to know whether you want it and how it should be done.

Let me know if you'd like help with the first 2 (and 3, of course). I could make PRs.

[mvkara]

Short answer: Always happy for contributions, as long as they are done appropriately.

Long answer:

1. I would be willing to add a mutable vs immutable benchmark, as long as it is a separate benchmark from the main set which should be relatively straightfoward. As you are probably aware if I'm choosing an immutable collection it is often because a mutable one may be less performant for my use case (e.g. doing lots of clones, locking, etc) so it isn't entirely like-for-like. Right tool for right job.
2. a. Missing key lookup given the algorithm I don't see as much different in performance to where an item is in the map. A benchmark could prove me wrong of course but just from my understanding of the code it mostly has to do the same amount of work. b. While I may find these cases less useful doesn't mean other's won't find them more useful. Happy to add this. Of course most of my optimisation effort was in the "GetKey/Exists" operation as that's what I needed when I set out building this library. A toSeq benchmark may expose more performance optimisation opportunities.
3. I would be interested in M1 Pro results, but I'm hesitant to add them to the benchmark as the reference or clutter the documentation with another set of benchmarks. The benchmarks are there more to help optimise the library further where required and ensure minimal regressions across different sizes of collection.

[mvkara]

Closing this issue as inactive.