是什么让 Enum.HasFlag 这么慢？

Question

我正在做一些速度测试，我注意到 Enum.HasFlag 比使用按位运算慢了大约 16 倍。

有谁知道 Enum.HasFlag 的内部结构以及它为什么这么慢？我的意思是慢两倍不会太糟糕，但是当它慢 16 倍时它会导致函数无法使用。

如果有人想知道，这是我用来测试其速度的代码。

using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Linq;

namespace app
{
    public class Program
    {
        [Flags]
        public enum Test
        {
            Flag1 = 1,
            Flag2 = 2,
            Flag3 = 4,
            Flag4 = 8
        }
        static int num = 0;
        static Random rand;
        static void Main(string[] args)
        {
            int seed = (int)DateTime.UtcNow.Ticks;

            var st1 = new SpeedTest(delegate
            {
                Test t = Test.Flag1;
                t |= (Test)rand.Next(1, 9);
                if (t.HasFlag(Test.Flag4))
                    num++;
            });

            var st2 = new SpeedTest(delegate
            {
                Test t = Test.Flag1;
                t |= (Test)rand.Next(1, 9);
                if (HasFlag(t , Test.Flag4))
                    num++;
            });

            rand = new Random(seed);
            st1.Test();
            rand = new Random(seed);
            st2.Test();

            Console.WriteLine("Random to prevent optimizing out things {0}", num);
            Console.WriteLine("HasFlag: {0}ms {1}ms {2}ms", st1.Min, st1.Average, st1.Max);
            Console.WriteLine("Bitwise: {0}ms {1}ms {2}ms", st2.Min, st2.Average, st2.Max);
            Console.ReadLine();
        }
        static bool HasFlag(Test flags, Test flag)
        {
            return (flags & flag) != 0;
        }
    }
    [DebuggerDisplay("Average = {Average}")]
    class SpeedTest
    {
        public int Iterations { get; set; }

        public int Times { get; set; }

        public List<Stopwatch> Watches { get; set; }

        public Action Function { get; set; }

        public long Min { get { return Watches.Min(s => s.ElapsedMilliseconds); } }

        public long Max { get { return Watches.Max(s => s.ElapsedMilliseconds); } }

        public double Average { get { return Watches.Average(s => s.ElapsedMilliseconds); } }

        public SpeedTest(Action func)
        {
            Times = 10;
            Iterations = 100000;
            Function = func;
            Watches = new List<Stopwatch>();
        }

        public void Test()
        {
            Watches.Clear();
            for (int i = 0; i < Times; i++)
            {
                var sw = Stopwatch.StartNew();
                for (int o = 0; o < Iterations; o++)
                {
                    Function();
                }
                sw.Stop();
                Watches.Add(sw);
            }
        }
    }
}

结果：

HasFlag: 52ms 53.6ms 55ms
Bitwise: 3ms 3ms 3ms

Answer 1

有谁知道 Enum.HasFlag 的内部结构以及它为什么这么慢？

实际检查只是Enum.HasFlag 中的一个简单位检查 - 这不是问题所在。话虽如此，它比您自己的位检查要慢...

这种放缓有几个原因：

首先，Enum.HasFlag 进行显式检查以确保 enum 的类型和标志的类型都是相同的类型，并且来自同一个 Enum。这张支票有一些费用。

其次，在转换为UInt64 的过程中，在HasFlag 内部出现了一个不幸的值的框和拆箱。我相信这是因为Enum.HasFlag 需要与所有枚举一起工作，而不管底层存储类型如何。

话虽如此，Enum.HasFlag 有一个巨大的优势——它可靠、干净，并且使代码非常明显和富有表现力。在大多数情况下，我觉得这值得付出代价 - 但如果您在性能非常关键的循环中使用它，则可能值得自己检查。

Answer 2

Enum.HasFlags() 的反编译代码如下：

public bool HasFlag(Enum flag)
{
    if (!base.GetType().IsEquivalentTo(flag.GetType()))
    {
        throw new ArgumentException(Environment.GetResourceString("Argument_EnumTypeDoesNotMatch", new object[] { flag.GetType(), base.GetType() }));
    }
    ulong num = ToUInt64(flag.GetValue());
    return ((ToUInt64(this.GetValue()) & num) == num);
}

如果我猜的话，我会说检查类型是最慢的原因。

请注意，在最新版本的 .Net Core 中，这已得到改进，Enum.HasFlag 编译为与使用按位比较相同的代码。

Answer 3

本页讨论的boxing 导致的性能损失也会影响公共.NET 函数Enum.GetValues 和Enum.GetNames，它们分别转发到(Runtime)Type.GetEnumValues 和(Runtime)Type.GetEnumNames。

所有这些函数都使用（非泛型）Array 作为返回类型——这对于名称来说还不错（因为 String 是一个引用类型）——但对于 @ 987654331@ 值。

下面是有问题的代码 (.NET 4.7)：

public override Array /* RuntimeType.*/ GetEnumValues()
{
    if (!this.IsEnum)
        throw new ArgumentException();

    ulong[] values = Enum.InternalGetValues(this);
    Array array = Array.UnsafeCreateInstance(this, values.Length);
    for (int i = 0; i < values.Length; i++)
    {
        var obj = Enum.ToObject(this, values[i]);   // ew. boxing.
        array.SetValue(obj, i);                     // yuck
    }
    return array;              // Array of object references, bleh.
}

我们可以看到，在进行复制之前，RuntimeType 再次返回到System.Enum 以获取一个内部数组，这是一个根据需要为每个特定的Enum 缓存的单例。另请注意，此版本的值数组确实使用了正确的强签名ulong[]。

这是 .NET 函数（我们现在又回到了System.Enum）。有一个类似的函数用于获取名称（未显示）。

internal static ulong[] InternalGetValues(RuntimeType enumType) => 
    GetCachedValuesAndNames(enumType, false).Values;

看到返回类型了吗？这看起来像是我们想要使用的函数...但首先考虑 .NET 每次重新复制数组的第二个原因（如您在上面看到的）是 .NET 必须确保每个调用者都获得未更改的副本原始数据，因为恶意编码员可以更改她返回的Array 的副本，从而引入持续损坏。因此，重新复制预防措施尤其旨在保护缓存的内部主副本。

如果您不担心这种风险，也许是因为您确信自己不会意外更改数组，或者可能只是为了勉强进行几个周期（这肯定为时过早）优化，那么获取任何Enum 的名称或值的内部缓存数组副本：

        → 以下两个函数构成本文的总贡献←
→（但请参阅下面的编辑以了解改进的版本）←

static ulong[] GetEnumValues<T>() where T : struct =>
        (ulong[])typeof(System.Enum)
            .GetMethod("InternalGetValues", BindingFlags.Static | BindingFlags.NonPublic)
            .Invoke(null, new[] { typeof(T) });

static String[] GetEnumNames<T>() where T : struct =>
        (String[])typeof(System.Enum)
            .GetMethod("InternalGetNames", BindingFlags.Static | BindingFlags.NonPublic)
            .Invoke(null, new[] { typeof(T) });

请注意，T 的通用约束不足以保证 Enum。为简单起见，我不再检查struct 之外的任何其他内容，但您可能希望对此进行改进。同样为简单起见，这（引用和）每次都直接反映在MethodInfo 上，而不是尝试构建和缓存Delegate。这样做的原因是使用非公共类型RuntimeType 的第一个参数创建正确的委托很乏味。下面再详细介绍一下。

首先，我将总结使用示例：

var values = GetEnumValues<DayOfWeek>();
var names = GetEnumNames<DayOfWeek>();

和调试器结果：

'values'    ulong[7]
[0] 0
[1] 1
[2] 2
[3] 3
[4] 4
[5] 5
[6] 6

'names' string[7]
[0] "Sunday"
[1] "Monday"
[2] "Tuesday"
[3] "Wednesday"
[4] "Thursday"
[5] "Friday"
[6] "Saturday"

所以我提到Func<RuntimeType,ulong[]> 的“第一个论点”很烦人。但是，因为这个“问题”arg 恰好是第一个，所以有一个可爱的解决方法，您可以将每个特定的 Enum 类型绑定为其自己的委托的 Target，然后每个都是 reduced to Func<ulong[]>。）

显然，制作任何 那些 委托都是没有意义的，因为每个委托都只是一个总是返回相同值的函数......但同样的逻辑似乎适用于，也许不太明显，原来的情况也是如此（即Func<RuntimeType,ulong[]>）。尽管我们这里只有一个委托，但您永远不会真的想多次调用它每个枚举类型。无论如何，所有这一切都导致了一个更好的解决方案，它包含在下面的编辑中。

---

[编辑：]
这是同一事物的稍微更优雅的版本。如果您要为相同的 Enum 类型重复调用函数，则此处显示的版本将只对每个 Enum 类型使用一次反射。它将结果保存在本地可访问的缓存中，以便随后快速访问。

static class enum_info_cache<T> where T : struct
{
    static _enum_info_cache()
    {
        values = (ulong[])typeof(System.Enum)
            .GetMethod("InternalGetValues", BindingFlags.Static | BindingFlags.NonPublic)
            .Invoke(null, new[] { typeof(T) });

        names = (String[])typeof(System.Enum)
            .GetMethod("InternalGetNames", BindingFlags.Static | BindingFlags.NonPublic)
            .Invoke(null, new[] { typeof(T) });
    }
    public static readonly ulong[] values;
    public static readonly String[] names;
};

这两个函数变得微不足道：

static ulong[] GetEnumValues<T>() where T : struct => enum_info_cache<T>.values;
static String[] GetEnumNames<T>() where T : struct => enum_info_cache<T>.names;

此处显示的代码说明了一种将三个特定技巧组合在一起的模式，这些技巧似乎相互产生了一种异常优雅的惰性缓存方案。我发现这种特殊的技术有着惊人的广泛应用。

1. 使用通用静态类为每个不同的Enum 缓存数组的独立副本。值得注意的是，这会根据需要自动发生；

2. 与此相关，loader lock 保证了唯一的原子初始化，并且没有条件检查结构的混乱。我们还可以使用readonly 保护静态字段（出于显而易见的原因，它通常不能与其他惰性/延迟/需求方法一起使用）；

3. 最后，我们可以利用 C# type inference 自动将通用函数（入口点）映射到其各自的通用静态类中，这样需求缓存最终甚至被隐式驱动（即，最好的代码是不存在的代码——因为它永远不会有错误）

您可能注意到这里显示的特定示例并不能很好地说明第 (3) 点。 void-take 函数必须手动向前传播类型参数 T，而不是依赖类型推断。我没有选择公开这些简单的函数，以便有机会展示 C# 类型推断如何使整体技术大放异彩...

但是，您可以想象，当您做组合一个可以推断其类型参数的静态泛型函数时——即，您甚至不必在调用时提供它们网站——然后它变得非常强大。

关键的见解是，虽然泛型函数具有完整的类型推断能力，但泛型类没有，也就是说，编译器永远不会推断T如果您尝试调用以下第一行。但是我们仍然可以通过泛型函数隐式类型（最后一行）遍历它们来获得对泛型类的完全推断访问，以及由此带来的所有好处：

int t = 4;
typed_cache<int>.MyTypedCachedFunc(t);  // no inference from 't', explicit type required

MyTypedCacheFunc<int>(t);               // ok, (but redundant)

MyTypedCacheFunc(t);                    // ok, full inference

设计得当，推断类型可以毫不费力地让您进入适当的自动按需缓存数据和行为，为每种类型定制（回忆点 1. 和 2）。如前所述，我发现这种方法很有用，尤其是考虑到它的简单性。

Answer 4

JITter 应该将其内联为简单的按位操作。 JITter 足够了解甚至可以自定义处理某些框架方法（我认为是通过 MethodImplOptions.InternalCall？），但 HasFlag 似乎已经逃脱了 Microsoft 的严重关注。