FrozenDictionary offers faster reads but slower creation. Here’s when the trade-off makes sense.

The tl;dr-

Based on benchmark data, here are the break-even points where FrozenDictionary becomes worthwhile:

(Based on string keys and OrdinalIgnoreCase comparison.)

• Cache misses break-even faster – FrozenDictionary is much faster for failed lookups (0.33ns vs 6-7ns), so collections with cache misses justify the switch sooner.
• Creation cost scales ~linearly with size – Creation cost grows in a fairly linear way, so larger collections will need more reads to justify use.
• Read performance is consistent – Once created, FrozenDictionary maintains good performance regardless of collection size.

Switch to FrozenDictionary when you expect:

• Small collections (10-100 elements): Hundreds to low thousands of reads
• Large collections (1K+ elements): 10K+ reads with cache misses, or 20K+ reads with all hits
• A high percentage of misses: you can cut the number of reads in ~half if you expect a high percentage of key misses.

Instantiation costs

FrozenDictionary‘s creation penalty is substantial but decreases as collection size increases:

Hit + miss costs

The code

• DictionaryInstantiationTests.cs
• DictionaryLookupTests.cs
• Full tabular data