传递结构体列表vs类列表作为参数：200个不可变结构体的性能考量

好问题！咱们结合你给出的TankReading结构体和200个元素的列表场景，从几个关键角度来分析这个性能问题：

• 列表传递的本质：引用而非值拷贝
  首先要明确：.NET中的List<T>本身是引用类型，当你把它作为参数传入方法时，传递的是列表对象的引用（本质是一个8字节左右的指针，64位系统下），而不是列表里所有200个结构体的副本。这意味着你完全不用担心要复制200个结构体的开销——传递列表的成本和传递任何其他引用类型几乎一致。

• 结构体的大小开销可以忽略
  你的TankReading结构体仅包含一个DateTime（8字节）和一个double（8字节），总大小才16字节。就算是极端情况（比如传递数组且按值传递），200个这样的结构体总共也才3200字节（约3KB），这种量级的内存复制对现代CPU来说完全是微不足道的。更不用说你用的是List<T>，根本不会触发这种全量拷贝。

• 不可变结构体的性能优势
  你设计的是不可变结构体，这反而在性能上加分：因为结构体的状态不会被修改，方法中访问列表元素时，不需要额外的拷贝操作（除非你把元素取出赋值给局部变量，但这也只是16字节的轻量操作）。相比可变结构体，不可变设计既避免了意外的状态变更，又保留了值类型的性能特性。

• 200个元素的规模无性能压力
  200个元素的列表属于极小规模，哪怕是最严格的性能测试，这种传递方式的损耗也完全在可接受范围内。如果你的方法只是读取列表元素，几乎没有额外开销；如果需要做筛选、转换这类操作，开销主要来自新列表的内存分配和元素复制——这部分和结构体本身无关，换成引用类型列表也一样要承担。

总结一下：传递这个结构体列表作为参数从性能角度完全可行，甚至在你的场景下是非常合理的选择，完全不用顾虑性能问题。

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