List<struct> 与 List<class> 的性能

Question

出于好奇，我尝试同时使用value 和reference 类型来测试List<T> 的性能。

结果与我预期的不一样，这让我相信我对这些对象在内存中的布局方式的理解可能不正确。

这是我的实验：

• 创建一个基本的class，只包含两个成员，一个int 和一个bool

• 创建 2 个 List<T> 对象来保存我的测试类（List1 和 List2）

• 随机生成测试对象并交替添加到List1和List2

• 遍历List1 需要多长时间（执行一些任意工作，例如递增计数器然后访问元素）

然后我用struct 代替class 重复了一遍

我的假设是，当使用 class 时，List<T> 中的引用是连续的，但由于我创建它们的方式（在添加到 List1 和 List2 之间切换），它们的对象指向可能不会。

我认为当使用 struct 时，因为它是一种值类型，所以对象本身将连续保存在内存中（因为 List<T> 保存实际项目而不是引用集合）。

因此，我希望 struct 表现更好（由于预取器等）

事实上，两者非常相似。

这是怎么回事？

编辑 - 添加代码以实际访问迭代器中的元素，包括代码示例

测试类（或结构）

public class/struct TestClass
{
    public int TestInt;
    public bool TestBool;
}

创建随机列表：

var list1 = new List<TestClass>();
var list2 = new List<TestClass>();

var toggle = false;
for (var i=0; i < 4000000; i++)
{
    // Random object generation removed for simplicity

    if (toggle)
        list1.Add(randomObject);
    else
        list2.Add(randomObject);

    toggle = !toggle;    
}

测试：

var stopWatch = new Stopwatch();
var counter = 0;
var testBool = false;

stopwatch.Start();

foreach(var item in list1)
{
    // Access the element
    testBool = item.TestBool;
    counter++;
}

stopwatch.Stop();

将TestObject 重复为class 和struct。

我意识到没有太大区别，但我预计 struct 的性能明显优于 class

Answer 1

// Access the element
testBool = item.TestBool;

这没有任何效果，优化器将删除该语句，因为它没有有用的副作用。您实际上并没有衡量结构和类之间的区别，因为您从未真正访问过元素。

counter++;

同样的故事，很可能会被优化掉。除非您在循环完成后真正使用 计数器值。让优化器删除太多代码并使测试变得毫无意义是一种常见的微基准风险。解决方法是：

foreach(var item in list1)
{
    // Access the element
    counter += item.TestInt;
}
Console.WriteLine(counter);

基准指南是：

• 仅由发布配置生成的配置文件代码。 Debug 版本会产生过多的额外代码并抑制优化
• Tools + Options，Debugging，General，取消勾选“Suppress JIT optimization on module load”。这可确保即使您使用调试器运行也能获得优化的代码
• Debug + Windows + Disassembly 是一个非常重要的调试器窗口，它可以显示真正运行的代码。正确解释该窗口需要对机器代码有所了解
• 在测试代码周围放置一个外循环非常重要，以确保您至少运行 10 次测试。这消除了冷启动效应，例如处理器必须填充 L1 指令高速缓存以及抖动必须从程序集中加载 IL 并在第一次执行时对其进行编译。并消除随机异常值，因为您必须与机器上运行的其他进程竞争并竞争处理器。
• 15% 的差异没有统计学意义。

Answer 2

如果您实际上并未访问存储在列表中的类对象的成员，那么以下两种类型应该提供等效的迭代性能。

1. List<IntPtr>
2. List<object>

即使引用类型 instances 没有填充内存的连续部分，references 本身也是。

上述情况的例外情况是，如果 CLR 在执行内存小于 32GiB 的 64 位应用程序时压缩指针。此策略在 JVM 中记录为 Compressed OOPS。但是，x86-64 指令集包含允许此压缩/解压缩非常高效执行的指令，因此即使在这种情况下，您也应该看到类似于List<int> 的性能。

当您的值类型超过指针的大小 (IntPtr.Size) 时，事情就会变得有趣。在那之后，包含引用的List<T> 的性能应该很快超过值类型的List<T> 的性能。这是因为无论您的引用类型 instance 有多大，对该实例的 reference 最多为 IntPtr.Size。