c# System.Collections.Immutable 集合的性能开销

应避免在高频场景中滥用不可变集合：ImmutableArray 修改开销大，ImmutableList 随机访问慢于 List，ImmutableHashSet 适合多线程共享或需历史版本的场景；优先复用 Builder、预设容量、避免短生命周期 Builder，并警惕旧版本引用导致的冗余分配与 GC 压力。

ImmutableArray 的内存分配开销比 T[] 高得多

每次调用 ImmutableArray.Add() 或 ImmutableArray.SetItem() 都会创建新数组对象，底层触发 Array.Copy() 或 Array.Resize()。这不是“修改原数组”，而是构造全新副本——哪怕只改一个元素，也要复制整个底层数组。

实操建议：

• 避免在 tight loop（如每帧更新、高频事件处理）中反复调用 Add() 或 Builder.Add() 后再 ToImmutable()；改用 ImmutableArray.CreateBuilder() 累积，最后一次性转出
• 若已知大小，优先用 ImmutableArray.Create(params T[] items) 或 ImmutableArray.Empty.AddRange(items)，避免 Builder 内部多次扩容
• ImmutableArray 本身是 struct，但其内部持有的 T[] 是 heap 对象；大量小数组（如 ImmutableArray 长度为 1–5）会导致堆碎片加剧

ImmutableList 查找和索引访问比 List 慢 2–5 倍

ImmutableList 底层是平衡树（AVL tree），不是数组。这意味着 list[i] 不是 O(1)，而是 O(log n)；list.Contains(x) 也是 O(log n)，而非 List.Contains() 的 O(n) ——但常数因子更大，实际性能更差。

常见错误现象：

• 把 ImmutableList 当作 List 替代品用于频繁随机访问场景（如 UI 列表渲染、物理引擎粒子索引）
• 误以为 ImmutableList.ToImmutableArray() 是零拷贝转换——它仍要遍历整棵树并分配新数组
• 未注意 ImmutableList.Value 属性已废弃，直接访问 list[i] 就是树遍历

何时该用 ImmutableHashSet 而不是 HashSet

只有当你需要「历史版本保留」或「多线程安全共享」且不希望加锁时，

ImmutableHashSet 才有存在价值。它的插入/查找平均仍是 O(1)，但哈希桶结构是不可变的 trie，每次变更都重建部分 trie 节点，带来额外指针跳转和 GC 压力。

使用场景对比：

• 单线程、写少读多 → 用 HashSet + ReadOnlySet 包装更轻量
• 需记录“上一帧集合状态”供回滚 → ImmutableHashSet 可直接保存引用，无需深拷贝
• 跨 Task 共享集合且拒绝锁 → ImmutableHashSet 避免 ConcurrentDictionary 的复杂同步逻辑
• 注意：ImmutableHashSet.Union() 和 Intersect() 并非就地合并，而是生成新实例；若链式调用多次，务必用 var result = set1.ToBuilder().UnionWith(set2).UnionWith(set3).ToImmutable();

Builder 模式不是银弹，过度使用反而更慢

ImmutableArray.CreateBuilder()、ImmutableList.ToBuilder() 等确实能减少中间对象，但它们本身是 class，每次调用 ToImmutable() 仍要执行一次完整结构重建（如数组拷贝、树重平衡）。如果 builder 生命周期短、复用率低，开销可能比直接用可变集合还高。

性能关键点：

• builder 复用很重要：不要在方法内 new builder → 操作 → ToImmutable() → return；应作为字段或池化对象复用
• ImmutableArray.CreateBuilder(initialCapacity) 显式指定容量，避免 builder 内部数组多次 resize
• 对纯追加场景，List + 最后一次 ToArray() 或 AsReadOnly() 往往比 builder + immutable 更快
• 调试时留意 GC 第 0 代回收频率——Immutable* 类型高频分配极易引发 GC Storm

真正影响性能的往往不是“不可变”这个概念，而是你是否在不该持久化的路径上保留了旧版本引用。比如缓存了一个 ImmutableList 实例却从未复用，又在下一帧新建另一个——这时你付出的是双倍内存+双倍构建时间，而收益为零。