明明有更好的hash方法

有位朋友對我吐槽前幾天我列舉的在源生成器的生成db映射實體的優(yōu)化點 提前生成部分 hashcode 進行比較

所示代碼

public static void GenerateReadTokens(this IDataReader reader, Span s)
{
    for (int i = 0; i < reader.FieldCount; i++)
    {
        var name = reader.GetName(i);
        var type = reader.GetFieldType(i);
        switch (EntitiesGenerator.SlowNonRandomizedHash(name))
        {
            
            case 742476188U:
                s[i] = type == typeof(int) ? 1 : 2; 
                break;

            case 2369371622U:
                s[i] = type == typeof(string) ? 3 : 4; 
                break;

            case 1352703673U:
                s[i] = type == typeof(float) ? 5 : 6; 
                break;

            default:
                break;
        }
    }
}

這里為什么不用 string.GetHashCode , 而要用 SlowNonRandomizedHash(name) ， 有更好的方法不用，真是傻

當(dāng)時俺也只能 囧 著臉給ta解釋 string.GetHashCode 真的沒辦法用，

可惜口頭幾句解釋再多，一時也無法擺脫ta鄙視的目光

只有在此多寫幾句“狡辯”

“狡辯”

首先其實 NormalizedHash 性能很強的，其實現(xiàn)如下

public static uint SlowNonRandomizedHash(this string? value)
{
    uint hash = 0;
    if (!string.IsNullOrEmpty(value))
    {
        hash = 2166136261u;
        foreach (char c in value!)
        {
            hash = (char.ToLowerInvariant(c) ^ hash) * 16777619;
        }
    }
    return hash;
}

但是不管性能強不強，也不是只能用這個方法的原因

其實真實原因很多人都知道，都是大家的默認常識了：net code string.GetHashCode 是隨機的，多次運行程序，同一個字符串可能會在每次運行都有不同的哈希值

比如 18年的文章 Why is string.GetHashCode() different each time I run my program in .NET Core?

這里簡單復(fù)述一下原文內(nèi)容

以這個非常簡單的程序為例，它連續(xù)兩次調(diào)用一個字符串GetHashCode()

using System;

static class Program
{
    static void Main(string[] args)
    {
        Console.WriteLine("Hello World!".GetHashCode());
        Console.WriteLine("Hello World!".GetHashCode());
    }
}

如果在 .NET Framework 上運行此程序，則每次運行該程序時，都會獲得相同的值：

> dotnet run -c Release -f net471
-1989043627
-1989043627

> dotnet run -c Release -f net471
-1989043627
-1989043627

> dotnet run -c Release -f net471
-1989043627
-1989043627

相反，如果為 .NET Core 編譯同一程序，則在同一程序執(zhí)行中每次調(diào)用都會獲得相同的值，但對于不同的程序執(zhí)行，將獲得不同的值：GetHashCode()

> dotnet run -c Release -f netcoreapp2.1
-1105880285
-1105880285

> dotnet run -c Release -f netcoreapp2.1
1569543669
1569543669

> dotnet run -c Release -f netcoreapp2.1
-1477343390
-1477343390

努力查找之后，在 微軟官方文檔給出過使用GetHashCode()方法的建議 。其明確提示，不應(yīng)將GetHashCode()方法產(chǎn)生的hash值當(dāng)作為相同能持久化的值使用。

The hash code itself is not guaranteed to be stable. Hash codes for identical strings can differ across .NET implementations, across .NET versions, and across .NET platforms (such as 32-bit and 64-bit) for a single version of .NET. In some cases, they can even differ by application domain. This implies that two subsequent runs of the same program may return different hash codes.

為什么要用隨機化的 hash？

Stephen Toub 在一個 issue 中提到了這個問題的答案:

Q: Why .NET Core utilize randomized string hashing?
問：為什么 .NET Core 使用隨機字符串哈希？
A: Security, prevention against DoS attacks, etc.
A：安全性、防止 DoS 攻擊等。

原文很詳細的解釋有關(guān)安全的內(nèi)容，這里就不作詳細復(fù)述了

那么有沒有更好的 hash 方法呢？

當(dāng)然肯定是有的，string 類內(nèi)部其實就有，

感興趣的童鞋可以閱讀源碼 https://github.com/dotnet/runtime/blob/main/src/libraries/System.Private.CoreLib/src/System/String.Comparison.cs#L923

里面 大小寫敏感和不敏感都有實現(xiàn)， 其代碼比上面18年文章列舉的方法還有更多性能優(yōu)化

不過內(nèi)部方法，我們沒有辦法可以直接使用

但是呢？ 我們有黑魔法可以直接使用

public static partial class StringHashing
{
    [UnsafeAccessor(UnsafeAccessorKind.Method, Name = "GetNonRandomizedHashCodeOrdinalIgnoreCase")]
    public static extern int Hash(this string c);
}

比較一下

我們都寫到這里了，不比一下性能，大家肯定不服氣

來一段簡單的比較

[ShortRunJob, MemoryDiagnoser, Orderer(summaryOrderPolicy: SummaryOrderPolicy.FastestToSlowest), GroupBenchmarksBy(BenchmarkLogicalGroupRule.ByCategory), CategoriesColumn]
public class StringHashingBenchmarks
{
    [Params(0, 1, 10, 100)]
    public int Count { get; set; }

    public string Str { get; set; }

    [GlobalSetup]
    public void Setup()
    {
        var s = string.Join("", Enumerable.Repeat("_", Count));
        var b = Encoding.UTF8.GetBytes(s);
        Random.Shared.NextBytes(b);
        Str = Encoding.UTF8.GetString(b);
    }

    [Benchmark(Baseline = true)]
    public int GetHashCode()
    {
        return Str.GetHashCode();
    }

    [Benchmark]
    public uint SlowNonRandomizedHash()
    {
        return Str.SlowNonRandomizedHash();
    }

    [Benchmark]
    public int NonRandomizedHash()
    {
        return Str.Hash();
    }
}

結(jié)果

BenchmarkDotNet v0.13.12, Windows 11 (10.0.22631.3880/23H2/2023Update/SunValley3)
13th Gen Intel Core i9-13900KF, 1 CPU, 32 logical and 24 physical cores
.NET SDK 9.0.100-preview.6.24328.19
  [Host]   : .NET 8.0.7 (8.0.724.31311), X64 RyuJIT AVX2
  ShortRun : .NET 8.0.7 (8.0.724.31311), X64 RyuJIT AVX2

Job=ShortRun  IterationCount=3  LaunchCount=1  
WarmupCount=3  

當(dāng)然，我們比較的 hash code 是大小寫敏感的， 而其他兩個是大小寫不敏感的，

但是其差距都非常小，所以可以說都是很強的方法了

可惜 UnsafeAccessor 這些黑魔法無法在源生成器中使用