将IEnumerable初始化为List/Queue/Stack的性能开销是多少？

你的猜想是错误的，该构造方法不存在O(1)的零拷贝实现，实际时间复杂度为O(N)，N为源集合的总元素量。

内部实现逻辑 #

该构造函数的执行逻辑分两类场景，两类都涉及完整的元素遍历/拷贝：

• 若传入的集合实现了ICollection<int>接口（例如List<int>、int数组、HashSet<int>等常见集合类型）：
  构造函数会先读取集合的Count属性，一次性分配大小匹配的内部存储数组，随后调用CopyTo方法将源集合的所有元素完整拷贝到新List的内部数组中，全程没有跳过元素、直接引用源内存的逻辑。
• 若传入的集合未实现ICollection<int>接口（例如LINQ的Where/Select返回的延迟迭代器、自定义枚举器）：
  构造函数无法提前获取元素总数，会逐一枚举源序列的元素，每添加一个元素前检查内部数组容量，容量不足时按当前容量翻倍的规则扩容（每次扩容都涉及旧数组到新数组的全量拷贝），直到枚举完所有元素。该场景的开销比前一种更高，额外包含多次扩容的数组复制成本。

不存在“仅记录遍历起始位置、不拷贝元素”的可能性：List的底层是连续内存的数组结构，必须持有独立的内存存储自身元素，既无法复用非连续存储的源集合（例如链表、延迟迭代器根本没有连续内存块可以引用），也无法在持有其他集合内存引用的前提下保证自身的修改、扩容逻辑不会影响源集合。

方案选型参考 #

你可以根据自己的业务场景选对应方案：

• 当需要剔除的元素占总元素比例较高（比如超过20%）、或者你已经通过LINQ等方式拿到了过滤后的IEnumerable<int>结果时，直接构造新List的开销更低：如果手动在原集合上调用Remove/RemoveAt，每次删除非尾部元素时，都需要将删除位置之后的所有元素向前移位，批量删除的时间复杂度很容易达到O(N²)，尤其是删除集合头部、中部元素时性能极差。
• 当需要剔除的元素占比极低（比如百万级元素仅删除个位数元素）、且待删除元素基本集中在集合尾部时，手动调用Remove/Pop/Dequeue的开销更小，不需要额外分配新的整块内存、做全量元素拷贝。

以百万级int元素的场景做参考：全量拷贝构造新List的耗时通常在1毫秒以内，内存开销约为4MB（int占4字节），常规业务场景下这个开销完全可接受，如果是高频次执行该操作，建议结合实际删除比例压测后再决策。

内容的提问来源于stack exchange，提问作者user18908005