C# for循环和Array.Fill的性能差异

Question

C# for循环和Array.Fill的性能差异

9

我使用 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循环更快，但后来我查看了.NET Core源代码，发现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 快一点，尽管在底层它们使用的是完全相同的代码。你能解释一下原因吗？或者我只是错误地读取了结果？

- Martin Zikmund

3

你是否以发布模式编译了你的代码？ - Pretasoc

框架二进制文件已经生成了高度优化的本地映像（不确定是“仅仅”是ngen，还是某个定制版本）。因此，即使您完全复制代码并以发布模式编译，框架版本的更改也可能会更快。 - Zastai

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Adriano Repetti · Accepted Answer

我对 Enumerable.Repeat() 感到惊讶，与我的初步想法相反，它的扩展能力很好。不管怎样，回答你的问题：当你使用 For() 时，你会重复访问一个类成员，而调用 Array.Fill() 时，你仅获取一次其地址。

更令我惊讶的是编译器并没有检测出来 - 并进行优化 - 这一点，但要读取类成员的值，你需要使用 ldarg.0 获取 this 的值，然后使用 ldfld ForVsFillVsEnumerable.data 获取其实际地址。在 ForVsFillVsEnumerable.Fill() 中，这只需要一次调用 Array.Fill() 就可以完成。

你可以编写自己的 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...在这种情况下，我会尝试测量更大的算法，其中这种差异更为明显（如果不是，则你不应该关心）。