【问题标题】:Is there a way to cast a generic enum value to an UInt64 value without allocating?有没有办法在不分配的情况下将通用枚举值转换为 UInt64 值?
【发布时间】:2018-12-26 07:45:34
【问题描述】:

我想要一种快速通用的方法来检查标有FlagsAttribute 的枚举值是否有效。为此,我创建了一个名为EnumInfo<T> 的类,它通过按位或运算枚举的所有不同值来计算其静态构造函数中的标志模式。然后,IsValidFlagsValue 方法只需通过与标志模式执行按位与比较来检查提供的值。

考虑以下 C# 代码

// This code requires C# 7.3
public static class EnumInfo<T> where T : Enum, IConvertible
{
    // This field is calculated in the static constructor
    public static readonly ulong FlagsPattern; 

    public static bool IsValidFlagsValue(this T enumValue)
    {
        // The actual problem is here: ToUInt64 allocates (because of internal boxing?)
        var convertedUInt64Value = enumValue.ToUInt64(null);
        return (FlagsPattern & convertedUInt64Value) == convertedUInt64Value;
    }
}

我的实际问题如下:为了重用这段代码,我将枚举值转换为类型ulong。但是,enumValue.ToUInt64(null) 在内部分配 24 字节,正如在以下基准测试中所见(使用 BenchmarkDotNet 执行):

public class ToUInt64Benchmark
{
    public IConvertible FlagsValue = 
        BindingFlags.Public | BindingFlags.Instance;

    [Benchmark]
    public ulong EnumToUInt64() => FlagsValue.ToUInt64(null);
}

目前有什么方法可以避免这种分配吗?我尝试使用不安全的代码,但我无法获取通用值的地址(即&amp;enumValue 不起作用)。有没有其他我没有想到的方法?

提前感谢您的帮助。

【问题讨论】:

  • 将泛型限制为struct, Enum(不需要IConvertible),然后也许使用Unsafe(类不是关键字)。还看到了 Enums.net 项目。他使用了一个很酷的技巧来将枚举转换为积分,但是它使用 fody (il rewriting) 来生成该方法的主体
  • @pinkfloydx33 你是我的英雄!详情见我的回答。

标签: c# performance memory enums garbage-collection


【解决方案1】:

正如pinkfloydx33 在这个问题的cmets 中指出的那样,System.Runtime.CompilerServices.Unsafe NuGet 包中有一个名为Unsafe 的类。有了它,您可以以不分配的不安全方式强制转换为 ulong。如果我们修改我的问题中的基准类,如下所示:

public class ToUInt64Benchmark
{
    public BindingFlags FlagsValue = BindingFlags.Public | BindingFlags.Instance;

    public IConvertible FlagsValueAsConvertible;

    public ToUInt64Benchmark() => FlagsValueAsConvertible = FlagsValue;

    [Benchmark(Baseline = true)]
    public ulong EnumToUInt64() => FlagsValueAsConvertible.ToUInt64(null);

    [Benchmark]
    public ulong UnsafeEnumToUInt64() => ConvertUnsafe(FlagsValue);

    private static unsafe ulong ConvertUnsafe<T>(T enumValue) where T : struct, Enum
    {
        var pointer = (ulong*)Unsafe.AsPointer(ref enumValue);
        return *pointer;
    }
}

...这导致以下结果:

它速度更快(在我的 Surface Pro 4 上的 .NET Core 2.2 中,ToUInt64 的执行时间仅为 10%),最重要的是,它不分配。

请务必在您的 csproj 文件中添加 AllowUnsafeBlocks 标签,以允许编译不安全代码。您不能在部分受信任的平台(例如 Silverlight)上运行此代码。这是我的 csproj 文件的结构。

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFrameworks>netcoreapp2.2;net472</TargetFrameworks>
    <DebugType>portable</DebugType>
    <PlatformTarget>x64</PlatformTarget>
    <LangVersion>7.3</LangVersion>
    <AllowUnsafeBlocks>true</AllowUnsafeBlocks>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="BenchmarkDotNet" Version="0.11.3" />
    <PackageReference Include="System.Runtime.CompilerServices.Unsafe" Version="4.5.2" />
  </ItemGroup>
</Project>

2018-12-26 17:00 UTC 更新

正如pinkfloydx33 在cmets 中正确指出的那样(再次),可以使用Unsafe.As 简化代码:

public class ToUInt64Benchmark
{
    // Other members omitted for brevity's sake
    [Benchmark]
    public ulong UnsafeEnumToUInt64() => ConvertUnsafe(FlagsValue);

    private static ulong ConvertUnsafe<T>(T enumValue) where T : struct, Enum => 
        Unsafe.As<T, ulong>(ref enumValue);
}

这对性能没有影响,但不需要 csproj 文件中的 AllowUnsafeBlocks 标签。

【讨论】:

  • 你能用Unsafe.As代替指针吗?那么你甚至不需要不安全的块。在此处查看第二个重载:docs.microsoft.com/en-us/dotnet/api/…
  • @pinkfloydx33 你又是对的,我已经更新了答案。
【解决方案2】:

你不能避免拳击同时使用接口。拳击的出现是因为你在 enumValue 上调用了一个接口方法。

如果您迫切希望避免额外的分配 - 忘记接口。高性能与完美的面向对象设计并不是密友。

【讨论】:

  • 我不同意:在EnumInfo&lt;T&gt; 中,我不是在接口类型上调用ToUInt64,而是在泛型类型上调用。这不涉及虚拟呼叫。您可以争辩说我在基准测试类中调用了ToUInt64,但请注意我在基准测试开始之前在构造函数中转换为IConvertible - 因此它不是测量的一部分(我不在乎这个调用需要多长时间,我的意思是这个调用在内部分配了 24 个字节)。您可以在此视频中了解有关 JIT 编译器如何处理泛型的更多信息:youtu.be/7GTpwgsmHgU?t=1680
  • 如果您查看Enum 类的IConvertible.ToUInt64 的实现,您会看到GetValue 被调用,其中包含值:referencesource.microsoft.com/#mscorlib/system/enum.cs,1006
  • 好吧,感谢您的链接,但我仍然认为,如果您试图避免这种额外分配,您应该摆脱抽象。
  • 尼克,我发布了另一个答案,我使用了 Pinkfloydx33 在 cmets 中指向我的 Unsafe 类。如您所见,它速度快且不分配。面向对象的设计不一定与高性能相矛盾。
猜你喜欢
  • 1970-01-01
  • 2012-12-05
  • 1970-01-01
  • 2015-03-17
  • 1970-01-01
  • 2019-08-27
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多