C# Frozen Collections: .NET 8 Performance Boost

John: Alright Lila, welcome to our co-authoring session. Today, we’re diving into a relatively new but incredibly useful feature in the .NET ecosystem: Frozen Collections. It’s a topic that’s been gaining traction, especially for developers keen on optimizing performance in C# applications.

Lila: Thanks, John! I’m excited to learn. “Frozen Collections”… it sounds intriguing. Like something out of a sci-fi movie where data gets cryogenically preserved? What exactly are they, and why the “frozen” metaphor?

John: That’s a fun way to put it! The “frozen” part essentially means these collections are immutable – once you create them, their contents cannot be changed. Think of it like a photograph; once taken, the scene it captures is fixed. This immutability is key to their power, especially for performance in read-heavy scenarios.

Lila: Immutable, okay. So, like `ImmutableList` or `ImmutableDictionary` that we’ve had for a while? What makes Frozen Collections different or special enough to get their own “frozen” branding?

John: Excellent question. While they share the immutability aspect with the `System.Collections.Immutable` types, Frozen Collections, introduced in .NET 8, are specifically optimized for extremely fast read operations – think lookups and enumerations. The internal data structures are fine-tuned for scenarios where you create the collection once and then access it many, many times without any modifications.

Table of Contents

Basic Info: Unpacking Frozen Collections

John: So, to lay the groundwork, Frozen Collections are a set of collection types in C# and .NET that, once populated, cannot be altered. This “write-once, read-many” characteristic is their defining feature. The primary problem they solve is providing high-performance, thread-safe access to static or rarely changing data.

Lila: “Thread-safe”… that rings a bell. Does their immutability automatically make them safe to use in multi-threaded applications without needing locks?

John: Precisely. Since the collection never changes after creation, multiple threads can read from it concurrently without any risk of data corruption or race conditions (situations where multiple threads access shared data and try to change it at the same time). This eliminates the need for complex and often performance-hindering synchronization mechanisms like `lock` statements when accessing the collection’s data.

Lila: That sounds like a big win for concurrent programming! So, if I have a set of configuration data or lookup values that my application loads at startup and then just reads from, Frozen Collections would be ideal?

John: Exactly. Perfect use case. Think of things like a dictionary of country codes to country names, a set of allowed user roles, or any dataset that’s established and then queried repeatedly. Before .NET 8, you might have used a `ReadOnlyDictionary` or an `ImmutableDictionary`. `ReadOnlyDictionary` is just a wrapper around a mutable dictionary, so it’s not truly immutable. `ImmutableDictionary` is genuinely immutable, but Frozen Collections take it a step further in terms of read performance optimization for certain access patterns.

Lila: And why specifically C# and .NET Core (or now just .NET, right?)? Is this a concept unique to this ecosystem?

John: Good point on the naming – yes, “.NET Core” has evolved into just “.NET” since .NET 5. The concept of immutable collections isn’t unique to .NET; many languages and platforms have similar ideas. However, `FrozenDictionary` and `FrozenSet` are specific implementations within the .NET Base Class Library (BCL), designed to leverage the .NET runtime’s capabilities for maximum efficiency. They were born out of a need identified within the .NET community and by Microsoft engineers to provide a “best-of-both-worlds” solution: the safety of immutability and even better read performance than existing immutable types for specific scenarios.

Supply Details: Availability & Versioning

Lila: So, if a developer wants to start using these, what do they need? You mentioned .NET 8?

John: Correct. Frozen Collections were officially introduced and made available with the release of .NET 8 in November 2023. This means you need to have the .NET 8 SDK (Software Development Kit) installed and your project must target .NET 8 or a later version.

Lila: So, if I’m working on an older project, say .NET 6 or .NET 7, I’m out of luck for now?

John: For the built-in `FrozenDictionary` and `FrozenSet` from `System.Collections.Frozen`, yes. You’d need to upgrade your project to .NET 8. This is often a good incentive to stay current with .NET versions, as each release brings performance improvements and new features like this.

Lila: How do you actually get them? Are they in a special NuGet package, or just part of the standard library once you’re on .NET 8?

John: They are part of the core libraries in .NET 8, specifically in the `System.Collections.Frozen` namespace. So, no extra NuGet packages are required for `FrozenDictionary` and `FrozenSet`. You just need to add a `using System.Collections.Frozen;` directive to your C# file.

Lila: That’s convenient. And are there different “flavors” or just these two main types?

John: The primary exposed types are `FrozenDictionary` and `FrozenSet`. These cover the most common use cases for immutable key-value pairs and unique item collections, respectively. Under the hood, the factory methods like `ToFrozenDictionary()` and `ToFrozenSet()` are quite smart. They analyze the input data and can choose different underlying specialized implementations to optimize for various scenarios, like small collections or specific key types, but this is an internal detail abstracted away from the developer.

Technical Mechanism: How Do They Work Their Magic?

John: This is where things get really interesting. The “magic,” as you call it, lies in the intense optimization during the “freezing” process. When you convert an existing collection (like a `List` or `Dictionary`) into a frozen one, .NET performs a one-time, potentially expensive, setup.

Lila: Expensive? So, creating them can be slow?

John: It can be slower than creating, say, a regular `Dictionary` or `HashSet`, yes. During this creation (or “freezing”) phase, the system analyzes the data – its size, the distribution of hash codes, etc. – and then constructs an internal data structure that is perfectly tailored for fast lookups on *that specific, unchanging set of data*. This might involve creating optimized hash tables with minimal collisions, or other specialized structures depending on the data’s characteristics.

Lila: So, it’s like building a custom-made, super-efficient filing system for a fixed set of documents, knowing you’ll never add or remove any?

John: Exactly! That’s a great analogy. Because it knows the data won’t change, it doesn’t need to accommodate future insertions, deletions, or resizes, which general-purpose collections must handle. This upfront investment in organization pays off massively with every subsequent read operation.

Lila: You mentioned `FrozenDictionary` and `FrozenSet`. How do they compare to their more common counterparts like `Dictionary` and `HashSet`, or even `ImmutableDictionary` and `ImmutableHashSet`?

John: Let’s break that down:

`Dictionary` vs `FrozenDictionary`: A regular `Dictionary` is mutable (changeable). It’s optimized for a balance of fast reads, writes, and updates. A `FrozenDictionary`, once created, is immutable and optimized purely for the fastest possible reads (`TryGetValue`, key enumeration). Creation is slower for `FrozenDictionary`.
`HashSet` vs `FrozenSet`: Similar story. `HashSet` is mutable, good for dynamic sets where you add/remove items and check for existence. `FrozenSet` is immutable, hyper-optimized for `Contains()` checks and enumeration on a fixed set. Again, creation takes longer for `FrozenSet`.
`ImmutableDictionary` vs `FrozenDictionary`: Both are immutable. `ImmutableDictionary` is designed to be efficiently “mutated” by creating new instances with changes (persistent data structures). This adds some overhead to its internal structure affecting read speed compared to `FrozenDictionary`. `FrozenDictionary` sacrifices this efficient “mutation” capability for raw read speed, as it’s truly “write-once.” If you need to “change” an immutable collection frequently by creating new versions, `ImmutableDictionary` is better. If you create it once and read it a million times, `FrozenDictionary` will likely be faster for those reads.
`ImmutableHashSet` vs `FrozenSet`: The same principle applies here as with the dictionaries. `ImmutableHashSet` allows for efficient creation of new set instances with modifications, while `FrozenSet` is geared towards maximum read performance on an absolutely static set of data.

Lila: So, the key is that upfront “freezing” cost. It analyzes the data to choose the best internal layout? Can you give an example of what kind of layouts it might choose?

John: Certainly. For instance, if you’re freezing a dictionary with a small number of string keys that are all distinct and have good hash code distribution, it might create a perfect hash table (where each key maps directly to a unique slot with no collisions). Or, for very small collections, it might even resort to a simple linear scan if that proves faster than hash table overhead. For larger collections or more complex key types, it uses highly optimized hashing strategies. The `System.Collections.Frozen` library contains several internal dictionary and set implementations, and `ToFrozenDictionary()` / `ToFrozenSet()` acts as a factory that picks the most appropriate one based on the characteristics of the input collection during the freezing process.

Lila: That’s quite sophisticated! So, as a developer, I don’t need to worry about *which* internal optimization it’s using; I just trust that `ToFrozenSet()` or `ToFrozenDictionary()` will do the best job?

John: Precisely. The beauty is in the abstraction. You provide your data, call the appropriate `ToFrozen…()` extension method, and you get back an interface (`IReadOnlyDictionary` or `IReadOnlySet`) that is backed by this highly optimized, immutable structure.

Lila: How do you actually create them? Is it like `new FrozenDictionary()`?

John: Not directly with a public constructor in most cases. You typically create a standard mutable collection first, like a `List`, `Dictionary`, or `HashSet`, populate it, and then call an extension method like `ToFrozenSet()` or `ToFrozenDictionary()` on it. For example:
var myData = new List<string> { "apple", "banana", "cherry" }; FrozenSet<string> frozenFruit = myData.ToFrozenSet();

var myMap = new Dictionary<int, string> { {1, "One"}, {2, "Two"} }; FrozenDictionary<int, string> frozenNumbers = myMap.ToFrozenDictionary();
These `ToFrozen…()` methods handle the optimization process I mentioned earlier.

Lila: Okay, that makes sense. You build it normally, then “freeze” it for optimized reading. And after it’s frozen, if I try to call an `Add` or `Remove` method, what happens?

John: Those methods simply don’t exist on `FrozenDictionary` or `FrozenSet` because they typically implement read-only interfaces like `IReadOnlyDictionary` and `IReadOnlySet`. You’ll get a compile-time error if you try to modify them, which is great for ensuring immutability is enforced by the type system itself.

Development & Ecosystem: The People Behind the Code

John: Features like Frozen Collections don’t just appear out of thin air. They are a result of the ongoing evolution of the .NET platform, driven by Microsoft and a very active open-source community.

Lila: So, Microsoft engineers primarily develop these features?

John: Microsoft employs many of the core .NET architects and developers who design and implement significant parts of the runtime and Base Class Library (BCL), which includes `System.Collections.Frozen`. However, .NET is open source, primarily on GitHub. This means proposals for new features, like frozen collections, often start as discussions or issues raised by the community or Microsoft engineers themselves. There’s a public API review process, and community members can contribute code, report bugs, and suggest improvements.

Lila: That’s cool. So, it’s a collaborative effort. Where would a developer go if they have questions, run into issues, or want to learn more from the community?

John: There are several excellent resources:

Official .NET Documentation: Microsoft Learn (docs.microsoft.com/dotnet) is the definitive source for API references and conceptual explanations.
GitHub Repositories: The `dotnet/runtime` repository is where much of the BCL development happens. You can see discussions, issues, and even the source code for frozen collections there.
Stack Overflow: A classic for specific programming questions, tagged with `c#`, `.net`, and potentially `frozen-collections`.
.NET Blogs: The official .NET Blog and blogs by prominent .NET community members often cover new features and best practices.
Developer Communities: Platforms like Reddit (e.g., r/csharp, r/dotnet), Discord servers, and local .NET meetups are great for discussion and learning.

Lila: It sounds like a strong ecosystem. So, the development isn’t happening in a vacuum; it’s responsive to real-world needs.

John: Absolutely. Performance is a perennial concern for developers, and features like frozen collections directly address the need for faster data access in common scenarios. The .NET team actively benchmarks and looks for optimization opportunities, and community feedback plays a vital role in prioritizing these efforts.

Use-Cases & Future Outlook

Lila: We touched on some use-cases earlier, like configuration data. Can you elaborate on other practical scenarios where frozen collections would really shine?

John: Certainly. Beyond static configuration, consider:

Caching Layers: If you have an in-memory cache that’s populated once (or infrequently updated by replacing the entire frozen collection), frozen collections can provide very fast cache lookups.
Routing Tables: In web applications or network services, mapping request paths or identifiers to handlers. These tables are often built at startup.
Metadata Dictionaries: Storing metadata about objects, types, or database schemas that doesn’t change during runtime.
Sets of Valid Tokens/Identifiers: If you have a known set of valid API keys, feature flags, or any identifiers that need quick existence checks.
Finite State Machines: Representing states and transitions where the structure is fixed.
Internationalization/Localization: Storing translation strings for a specific language, loaded once.

Essentially, any scenario where you have a collection whose contents are determined at startup or an infrequent point in time, and then primarily read from for the rest of the application’s lifecycle, is a prime candidate.

Lila: That’s a broad range! It seems like many applications could benefit. What about their future? Are there planned enhancements or other “frozen” things we might see?

John: The .NET team is always looking to expand on successful patterns. While specific future plans are best tracked through official .NET GitHub discussions and roadmaps, we can speculate. Perhaps we might see more specialized frozen collection types if strong use cases emerge. There’s also ongoing research into further optimization techniques for the freezing process or the internal structures themselves. The core principle – trading upfront creation cost for long-term read performance on immutable data – is powerful. We might also see more BCL APIs or ASP.NET Core features internally leverage frozen collections where appropriate for performance gains.

Lila: So, the foundation is solid, and it could be built upon. It’s not just a one-off feature, then?

John: Not at all. It’s part of a broader theme in .NET of providing developers with the right tools for high-performance, scalable applications. Immutability, specialized collections, and attention to low-level details are all part of that. As hardware evolves and application demands grow, such features become even more critical.

Competitor Comparison: Frozen vs. Other C# Collections

John: This is a crucial section for developers deciding what tool to use. We’ve touched on this, but let’s formalize the comparison, especially with performance in mind. The original article you found includes a benchmark, which is very insightful.

Lila: Right, the benchmark showed `FrozenSet` being significantly faster for lookups than `List`, and even faster than `HashSet` and `ImmutableHashSet`. That was surprising for `HashSet`!

John: It can be. `HashSet` is generally very fast for lookups (average O(1) time complexity – meaning lookup time is constant regardless of size). However, `FrozenSet` can sometimes eke out more performance because its internal structure is “baked” for that specific dataset. It doesn’t need the flexibility `HashSet` has to handle additions and removals, which can lead to a more compact and perfectly tuned hash table.
Let’s imagine a benchmark scenario, similar to the one in the InfoWorld article. We’d create a class, say `CollectionPerformanceBenchmark`:


using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Running;
using System.Collections.Frozen;

[MemoryDiagnoser] // To get memory allocation stats
public class CollectionPerformanceBenchmark
{
    private const int NumberOfItems = 10000; // Let's use a slightly larger number for more pronounced differences
    private readonly int _itemToSearch = NumberOfItems / 2; // An item we know is in the collections
    private readonly int _itemNotToSearch = NumberOfItems * 2; // An item we know is NOT in the collections

    private List<int> _list;
    private HashSet<int> _hashSet;
    private ImmutableHashSet<int> _immutableHashSet;
    private FrozenSet<int> _frozenSet;

    [GlobalSetup]
    public void SetupData()
    {
        var data = Enumerable.Range(0, NumberOfItems).ToList();
        _list = data; // List directly uses the data
        _hashSet = data.ToHashSet();
        _immutableHashSet = data.ToImmutableHashSet();
        _frozenSet = data.ToFrozenSet(); // This is the potentially slower creation step
    }

    // Baseline: List.Contains() - expected to be slowest for large N
    [Benchmark(Baseline = true)]
    public bool SearchList_Exists() => _list.Contains(_itemToSearch);

    [Benchmark]
    public bool SearchHashSet_Exists() => _hashSet.Contains(_itemToSearch);

    [Benchmark]
    public bool SearchImmutableHashSet_Exists() => _immutableHashSet.Contains(_itemToSearch);

    [Benchmark]
    public bool SearchFrozenSet_Exists() => _frozenSet.Contains(_itemToSearch);

    // Let's also test for non-existent items
    [Benchmark]
    public bool SearchList_NotExists() => _list.Contains(_itemNotToSearch);

    [Benchmark]
    public bool SearchHashSet_NotExists() => _hashSet.Contains(_itemNotToSearch);

    [Benchmark]
    public bool SearchImmutableHashSet_NotExists() => _immutableHashSet.Contains(_itemNotToSearch);

    [Benchmark]
    public bool SearchFrozenSet_NotExists() => _frozenSet.Contains(_itemNotToSearch);
}

// In Program.cs:
// BenchmarkRunner.Run<CollectionPerformanceBenchmark>();

Lila: So, `BenchmarkDotNet` is the standard tool for this kind of performance testing in .NET?

John: Yes, it’s the de facto standard. It handles warm-up, multiple iterations, statistical analysis, and helps avoid common micro-benchmarking pitfalls. The `[MemoryDiagnoser]` attribute is also great as it shows memory allocations, where frozen collections can also sometimes offer benefits due to their compact, optimized structures, though the primary win is speed.

Lila: What results would we expect from such a benchmark?

John: Generally, for the `Contains` operation on a reasonably large dataset (like 10,000 items):

`List.Contains()`: Will be the slowest, as it performs a linear search (O(n) complexity – lookup time grows with size).
`ImmutableHashSet.Contains()`: Will be much faster than `List`. It uses a tree-like structure (usually an AVL tree or similar balanced binary search tree) which gives it O(log n) complexity for lookups.
`HashSet.Contains()`: Typically faster than `ImmutableHashSet`. It uses a hash table, aiming for O(1) average time complexity.
`FrozenSet.Contains()`: Often the fastest, or at least highly competitive with `HashSet`. As discussed, its pre-optimized, fixed hash table can lead to fewer cache misses and more direct lookups. The difference between `FrozenSet` and `HashSet` might be more pronounced with string keys or more complex types where hashing and equality comparisons are more involved.

The key takeaway from benchmarks usually confirms that `FrozenSet` and `FrozenDictionary` excel in lookup speed once created.

Lila: So, when would I *not* choose a frozen collection, despite this speed?

John: That leads us nicely into the next part: risks and cautions. The main reasons are:

Data changes frequently: If your collection data needs to be modified often, frozen collections are unsuitable because you’d have to recreate the entire frozen collection each time, which is expensive. `Dictionary` or `HashSet` are better here.
Need efficient “copy-on-write” modifications: If you need an immutable collection but want to make “changes” by creating new versions efficiently (e.g., adding one item and getting a new immutable collection), then `ImmutableList`, `ImmutableHashSet`, or `ImmutableDictionary` are designed for this. They share structure between old and new instances.
Creation overhead is prohibitive: If the collection is created and used very briefly, or in a tight loop where creation speed matters more than subsequent read speed, the upfront cost of freezing might outweigh the benefits.
Very small collections: For extremely small collections (e.g., less than 5-10 items), the overhead of even a regular `HashSet` might not be worth it compared to a `List`, and the specialized optimizations in `FrozenSet` might offer negligible gains over `HashSet`. However, frozen collections do have special handling for small N, so they can still be good. Benchmarking your specific scenario is always key.

Risks & Cautions: When to Pause Before Freezing

John: We’ve touched on the main caution: the creation cost. The “freezing” process, where .NET analyzes the data and builds the optimized structure, is not free. It takes time and CPU resources.

Lila: So, if my application startup time is super critical, and I’m freezing a massive collection, that could be a bottleneck?

John: Precisely. If you have a very large dataset that needs to be frozen, you should measure the time it takes to call `ToFrozenDictionary()` or `ToFrozenSet()`. If it’s impacting your startup significantly, you might need to reconsider or find ways to do it asynchronously or in the background, if possible. However, for most common use-cases with moderately sized collections, this cost is usually acceptable given the long-term read performance benefits.

Lila: What about memory? Are they more memory-hungry because of these optimized structures?

John: It varies. Sometimes, the optimized structure can be more compact than a general-purpose one like `Dictionary` which might have overallocated arrays to accommodate future growth. Other times, the specialized structure might have a bit more overhead to enable the fast lookups. The `MemoryDiagnoser` in BenchmarkDotNet is your friend here. Generally, they are designed to be memory-efficient for their purpose, but it’s not their primary optimization goal over speed. The main thing is that once created, their memory footprint is stable.

Lila: Any other pitfalls? For example, what if my keys in a dictionary have really bad hash code implementations?

John: That’s a general problem for any hash-based collection, including `Dictionary`, `HashSet`, and their frozen counterparts. If your keys have poor `GetHashCode()` implementations (e.g., many different keys produce the same hash code), or if `Equals()` is very slow, performance will suffer across the board. Frozen collections will try their best to optimize, but they can’t magically fix fundamentally flawed key types. Good `GetHashCode()` and `Equals()` implementations are always crucial for performance with dictionary and set types.

Lila: So, the usual C# best practices for custom types still apply very much.

John: Absolutely. Garbage in, garbage out, or perhaps in this case, “slow keys in, slow frozen collection out,” relatively speaking. Though the freezing process might still build a more optimal structure for those bad keys than a general-purpose collection could.

Expert Opinions / Analyses (Woven into Dialogue)

John: Most .NET performance experts and community leaders have reacted very positively to Frozen Collections. Stephen Toub, a Partner Architect at Microsoft who works on .NET, often discusses performance intricacies in .NET, and features like these are right up his alley. The general consensus is that they fill an important niche for read-heavy, performance-sensitive scenarios.

Lila: So, the people who really live and breathe .NET performance see this as a valuable addition?

John: Yes. The key, as always, is understanding *when* to use them. They aren’t a silver bullet for all collection needs. But for their intended purpose – immutable, ultra-fast read access – they are a top-tier solution in the .NET toolkit. The analysis usually highlights the trade-off: higher initial creation cost for superior, sustained read performance and thread safety.

Lila: It’s like a specialized tool in a workshop. You wouldn’t use a sledgehammer for a finishing nail, but when you need to break concrete, it’s invaluable.

John: An excellent analogy, Lila. And like any specialized tool, knowing its strengths and weaknesses is key to using it effectively.

Latest News & Roadmap

John: As we mentioned, Frozen Collections arrived with .NET 8. With .NET 9 previews now rolling out, and subsequent versions on the horizon, the .NET team continues its focus on performance across the board. While there might not be “Frozen Collections v2” announced every year, the underlying JIT (Just-In-Time compiler), GC (Garbage Collector), and other runtime components are constantly being improved, which can indirectly benefit all code, including operations on frozen collections.

Lila: So, even if the Frozen Collections API itself doesn’t change much, they could get faster just from general .NET improvements?

John: Potentially, yes. Or new analysis techniques during the freezing process could be introduced. The .NET roadmap is usually published on their GitHub or blogs, and it’s always worth keeping an eye on the “Performance” and “BCL” sections for relevant news. For instance, sometimes a new release might include optimizations for specific types used as keys, like strings, which would benefit `FrozenDictionary`.

Lila: It’s good to know it’s part of a living, evolving platform.

John: Indeed. The commitment to performance and providing developers with optimized tools is a hallmark of modern .NET development.

FAQ: Quick Answers to Common Questions

Lila: Okay, let’s try to anticipate some common questions a beginner might have after reading all this. For example:
Q1: Are Frozen Collections a replacement for `List` or `Dictionary`?

John: A1: No, definitely not. `List` and `Dictionary` are general-purpose mutable collections vital for everyday programming where data changes. Frozen Collections are specialized for immutable, read-heavy scenarios where performance is critical.

Lila: Q2: When should I choose `ImmutableDictionary` over `FrozenDictionary`?

John: A2: Choose `ImmutableDictionary` (or `ImmutableHashSet` vs `FrozenSet`) when you need an immutable collection that you’ll “modify” by creating new instances with slight changes relatively often. Their persistent data structures are optimized for such “copy-on-write” updates. Choose `FrozenDictionary` when you create the collection once (or very infrequently) and then perform a high volume of reads, prioritizing absolute read speed.

Lila: Q3: Is there a `FrozenList`?

John: A3: As of .NET 8, the primary types are `FrozenDictionary` and `FrozenSet`. There isn’t a direct `FrozenList` in the same vein because lists are typically about ordered access by index, and the major optimization in frozen collections is for key-based lookups or `Contains` checks. For an immutable, indexed collection, `ImmutableList` is usually the go-to. If you need super-fast `Contains` on list-like data, you’d convert it to a `FrozenSet`.

Lila: Q4: Can I store `null` values in Frozen Collections?

John: A4: For `FrozenDictionary`, keys cannot be null, just like in a regular `Dictionary`. Values can be null if `TValue` is a reference type or a nullable value type. For `FrozenSet`, it depends on `T`. If `T` is a reference type, you can typically store one `null` value if the comparer allows it (the default one does). Behavior generally mirrors their mutable counterparts (`Dictionary`, `HashSet`).

Lila: Q5: What happens if I try to freeze an empty collection?

John: A5: It works perfectly fine. You’ll get an empty `FrozenDictionary` or `FrozenSet`. These are highly optimized for emptiness as well, so lookups will be extremely fast (and always return ‘not found’ or an empty enumeration).

Lila: Q6: How does the performance compare if the data for the frozen collection is very small, say 3 items?

John: A6: For very small N, `FrozenDictionary` and `FrozenSet` have specialized internal implementations. For instance, they might use a simple array and iterate through it, as this can be faster than the overhead of a hash table for just a few items. So, they are still very efficient. The performance gain over a `List` might be small, but the immutability and thread-safety benefits remain. Compared to `HashSet`, the lookup speed might be similar for tiny N, but the creation cost of the frozen version is still a factor to consider.

Our Mission

Design. Strategy. Brand.

About Us