各种数组元素复制方式的性能比较
2009-12-02 10:27 by 老赵, 7276 visits原本这只是“字符串”话题的一个分支，不过后来我发现这个问题单独来看也有一定参考价值，也有一些问题值得讨论的地方，其中也有一些问题希望得到高手指点，最终打算把这个话题独立处理。话不多说，现在就来看看。
这个话题是“复制数组元素”，它最简单的情况也就是把源数组的所有元素，一一复制到等长目标数组中去。在.NET中，我们可以使用多种方法来实现这个效果：
- 使用for语句一个个复制元素。
- 使用数组的CopyTo方法复制元素。
- 使用Array.Copy静态复制元素。
- 使用Buffer.BlockCopy复制元素。
于是使用如下代码进行实验：
int length = 1000 * 1000; var source = Enumerable.Repeat(100, length).ToArray(); var dest = new int[length]; int iteration = 1000; CodeTimer.Initialize(); CodeTimer.Time("One by one", iteration, () => { for (int i = 0; i < length; i++) dest[i] = source[i]; }); CodeTimer.Time("Int32[].CopyTo", iteration, () => { source.CopyTo(dest, 0); }); CodeTimer.Time("Array.Copy", iteration, () => { Array.Copy(source, dest, length); }); CodeTimer.Time("Buffer.BlockCopy", iteration, () => { Buffer.BlockCopy(source, 0, dest, 0, length * 4); });
运行结果如下（GC都是0，就省略了）：
One by one
Time Elapsed: 3,153ms
CPU Cycles: 7,570,978,116
Int32[].CopyTo
Time Elapsed: 2,933ms
CPU Cycles: 7,056,050,496
Array.Copy
Time Elapsed: 3,018ms
CPU Cycles: 7,244,562,468
Buffer.BlockCopy
Time Elapsed: 2,925ms
CPU Cycles: 7,014,908,760
我们发现，每种方法的性能其实都差不多，多次运行后发现，除了第一种方法（一一复制）的性能每次都会略差一些外，其他三种方法基本总是不相上下，时有胜负（可能Array.Copy和Buffer.BlockCopy胜利次数略多一些）。这和我起初的想象又有不同。我一开始认为后三种方法应该有较大领先才对，而Buffer.BlockCopy应该性能最好。因为在进行元素一一复制的时候，需要进行大量的下标计算，而每次读取和写入的时候也会为了避免GC造成对象地址变动而进行一些“固定”操作。而Array.Copy和Buffer.BlockCopy两个静态方法都是外部调用，CLR应该会为它们进行性能优化才对。
不过猜测总是敌不过测试数据——有机会还是看看汇编吧，用.NET Reflector看不出个所以然来。
那么，我们在实际使用过程中，应该使用哪种方式呢？
一一复制的方式最为灵活，您可以正着来，反着来，跳着来，爱咋来咋来；而CopyTo的灵活性最差，因为它只能复制数组的全部元素（事实上，CopyTo方法是ICollection接口的一部分）；Array.Copy静态方法的作用是把原数组中连续的一段，复制到目标数组中去，如果您不需要蹦蹦跳跳地前进，用Array.Copy是比较理想辅助函数。而最后一个Buffer.BlockCopy，它其实并不是在复制“元素”，它复制的是“字节”——因此，在上面的代码中，BlockCopy的最后一个参数为length * 4，这是因为一个32位整数占4个字节，其实我要复制的并非是length个元素，而是要复制length * 4个字节。
如下面的代码则是将一个长为100的int数组，复制到了长为100的long数组中去。此时，目标数组的每个元素为100L：
int length = 100; var source = Enumerable.Repeat(10, length).ToArray(); var destLong = new long[length]; Array.Copy(source, destLong, length);
而下面的代码，是把长度100的int数组的所有字节，复制到长为50的long数组里去。由于是字节级别的填充，因此目标数组的每个元素是42949672970L：
var destLong = new long[length / 2]; Buffer.BlockCopy(source, 0, destLong, 0, length * 4);
那么将int（32位整数）数组复制到byte（8位）或short（16位）上会是什么结果呢？会不会受到字节序的影响，而造成不同平台上的结果差异呢？我猜，应该不会吧，CLR在平台差异性问题上解决的其实不错。那如果没有区别的话，CLR又是怎么处理这个情况的呢？我不清楚，似乎也没有什么条件来实验，还是请高手来指点吧。
那么，下面的代码又会是什么情况呢？objest数组的每个元素都指到哪儿去了呢？
var objs = new object[length]; Buffer.BlockCopy(source, 0, objs, 0, length * 4);
结果是“抛出异常”。因为Buffer.BlockCopy只能复制基础类型（primitive）的数组，不能复制引用，也不能复制各种复杂的struct类型。因此，其实Buffer.BlockCopy理论上不能算是一种“数组元素复制方式”。
补充测试（引用数组）
经RFX大牛提示，在引用复制时会为了避免GC造成影响而使用Write Barrier，因此使用引用类型进行测试会有明显的效果。于是我们来补充一个测试：
int length = 1000 * 1000; var source = Enumerable.Repeat(new object(), length).ToArray(); var dest = new object[length]; int iteration = 1000; CodeTimer.Initialize(); CodeTimer.Time("One by one", iteration, () => { for (int i = length - 1; i >= 0; i--) dest[i] = source[i]; }); CodeTimer.Time("Int32[].CopyTo", iteration, () => { source.CopyTo(dest, 0); }); CodeTimer.Time("Array.Copy", iteration, () => { Array.Copy(source, dest, length); });
结果如下：
One by one
Time Elapsed: 7,298ms
CPU Cycles: 17,523,631,872
Int32[].CopyTo
Time Elapsed: 4,117ms
CPU Cycles: 9,823,501,236
Array.Copy
Time Elapsed: 4,225ms
CPU Cycles: 10,119,239,496
果然，我又弱了……
老赵给你发了两条短信息，你看一下，博客园的短信息