C# for-loop 和 Array.Fill 之间的性能差异

Posted 2023-03-15

【中文标题】C# for-loop 和 Array.Fill 之间的性能差异

【英文标题】：Performance difference between C# for-loop and Array.Fill

【发布时间】：2019-06-03 09:53:45

【问题描述】：

我使用BenchmarkDotNet 实现了以下基准测试：

public class ForVsFillVsEnumerable

    private bool[] data;

    [Params(10, 100, 1000)]
    public int N;

    [GlobalSetup]
    public void Setup()
    
        data = new bool[N];
    

    [Benchmark]
    public void Fill()
    
        Array.Fill(data, true);
    

    [Benchmark]
    public void For()
               
        for (int i = 0; i < data.Length; i++)
        
            data[i] = true;
        
    

    [Benchmark]
    public void EnumerableRepeat()
    
        data = Enumerable.Repeat(true, N).ToArray();
    

结果是：

BenchmarkDotNet=v0.11.3, OS=Windows 10.0.17763.195 (1809/October2018Update/Redstone5)
Intel Core i7-8700K CPU 3.70GHz (Coffee Lake), 1 CPU, 12 logical and 6 physical cores
.NET Core SDK=2.2.200-preview-009648
  [Host] : .NET Core 2.2.0 (CoreCLR 4.6.27110.04, CoreFX 4.6.27110.04), 64bit RyuJIT
  Core   : .NET Core 2.2.0 (CoreCLR 4.6.27110.04, CoreFX 4.6.27110.04), 64bit RyuJIT

Job=Core  Runtime=Core
           Method |    N |       Mean |      Error |      StdDev |     Median | Ratio | Rank |
----------------- |----- |-----------:|-----------:|------------:|-----------:|------:|-----:|
             Fill |   10 |   3.675 ns |  0.2550 ns |   0.7150 ns |   3.331 ns |  1.00 |    1 |
                  |      |            |            |             |            |       |      |
              For |   10 |   6.615 ns |  0.3928 ns |   1.1581 ns |   6.056 ns |  1.00 |    1 |
                  |      |            |            |             |            |       |      |
 EnumerableRepeat |   10 |  25.388 ns |  1.0451 ns |   2.9307 ns |  24.170 ns |  1.00 |    1 |
                  |      |            |            |             |            |       |      |
             Fill |  100 |  50.557 ns |  2.0766 ns |   6.1229 ns |  46.690 ns |  1.00 |    1 |
                  |      |            |            |             |            |       |      |
              For |  100 |  64.330 ns |  4.0058 ns |  11.8111 ns |  59.442 ns |  1.00 |    1 |
                  |      |            |            |             |            |       |      |
 EnumerableRepeat |  100 |  81.784 ns |  4.2407 ns |  12.5039 ns |  75.937 ns |  1.00 |    1 |
                  |      |            |            |             |            |       |      |
             Fill | 1000 | 447.016 ns | 15.4420 ns |  45.5312 ns | 420.239 ns |  1.00 |    1 |
                  |      |            |            |             |            |       |      |
              For | 1000 | 589.243 ns | 51.3450 ns | 151.3917 ns | 495.177 ns |  1.00 |    1 |
                  |      |            |            |             |            |       |      |
 EnumerableRepeat | 1000 | 519.124 ns | 21.3580 ns |  62.9746 ns | 505.573 ns |  1.00 |    1 |

最初我猜Array.Fill 做了一些优化，使其性能优于for-loop，但后来我检查了.NET Core source code，发现Array.Fill 的实现非常简单：

public static void Fill<T>(T[] array, T value)

    if (array == null)
    
        ThrowHelper.ThrowArgumentNullException(ExceptionArgument.array);
    

    for (int i = 0; i < array.Length; i++)
    
        array[i] = value;
    

性能足够接近，但似乎Fill 始终比for 快一点，即使在引擎盖下它是完全相同的代码。你能解释一下为什么吗？还是我只是看错了结果？

【问题讨论】：

你是否在发布模式下编译了你的代码？

框架二进制文件已经为它们生成了大量优化的本机图像（不确定它是“只是”ngen，还是一些自定义版本）。所以即使你完全复制代码并在发布模式下编译，更改框架版本也会更快。

【参考方案1】：

Enumerable.Repeat() 让我感到惊讶，这与我最初认为它的扩展性非常好相反。无论如何，回答您的问题：当您使用For() 时，您会重复访问一个班级成员，而当您调用Array.Fill() 时，您只会获得其地址一次。

令我更惊讶的是编译器没有检测到 - 并优化 - 但要读取类成员的值，您需要 ldarg.0 来获取 this 的值，然后 ldfld ForVsFillVsEnumerable.data 来获取它的实际值地址。在ForVsFillVsEnumerable.Fill() 中，只需调用一次即可调用Array.Fill()。

你可以检查这个编写你自己的填充函数：

[Benchmark]
public void For2()

    ForImpl(data);


private static void ForImpl(bool[] data)

    for (int i = 0; i < data.Length; i++)
    
        data[i] = true;
    

注意 1：无论性能如何，使用库函数总是更好，因为它可能会受益于未来的优化（例如，他们可能会决定为 Array.Fill() 添加特定的重载并使用本机代码实现它们 -对于某些架构 - 普通的 memset() 非常快）。

注意 2：如果循环代码非常小（而且速度很快），我会避免使用小向量（10 或 100 个项目）测量任何东西，因为设置适当的测试环境以可靠地测量几纳秒的差异非常困难.我认为 1000（甚至 100,000）是开始时的最低要求（即使在这种情况下，许多其他事情也会发挥相关作用......）除非你的实际用例是 10/100......in在这种情况下，我会尝试测量一个更大的算法，其中这种差异更加明显（如果不是，那么你不应该关心）。

【讨论】：

不要忘记在 IL 级别只应用了有限的优化 - JIT 将完成繁重的工作（与使用库函数的原因相同 - 这意味着您可以获得最大的效果通过改进 JITter）。对于您的 ForImpl 方法，使用 SharpLab.io 您将看到使用 data.Length 为版本生成的代码与将长度存储在本地的版本基本相同。 （嗯，比较被交换了，所以 jump-if-less 变成了 jump-if-greater，但这没什么。）

@Zastai 是的，我不希望在这种情况下将 data.Length outside for 更改生成的代码太多（编译器知道数组不需要每次都检索）。与原始代码的区别在于成员访问与参数。在处理类字段时，它会生成读取该字段的代码（这将成为基准测试的一部分，例如...在循环条件内的 C 程序中使用 strlen()），对于这样一个简单的循环来说，这是一个重要的影响