Span<T>
提供了极具竞争力的替代方案,而不必在您自己的应用程序的代码库中添加混乱和/或不可移植的绒毛:
// byte[] is implicitly convertible to ReadOnlySpan<byte>
static bool ByteArrayCompare(ReadOnlySpan<byte> a1, ReadOnlySpan<byte> a2)
{
return a1.SequenceEqual(a2);
}
可以在此处找到.NET Core 3.1.0以来的实现。
我修改了 @EliArbel的要点,将其添加为SpansEqual
,将大多数不那么有趣的执行器放入其他基准测试中,以不同的数组大小运行它,输出图形,并将其标记SpansEqual
为基线,以便它报告不同方法的比较结果。SpansEqual
。
下面的数字来自结果,对其进行了轻轻地编辑以删除“错误”列。
| Method | ByteCount | Mean | StdDev | Ratio |
|-------------- |----------- |-------------------:|------------------:|------:|
| SpansEqual | 15 | 3.562 ns | 0.0035 ns | 1.00 |
| LongPointers | 15 | 4.611 ns | 0.0028 ns | 1.29 |
| Unrolled | 15 | 18.035 ns | 0.0195 ns | 5.06 |
| PInvokeMemcmp | 15 | 11.210 ns | 0.0353 ns | 3.15 |
| | | | | |
| SpansEqual | 1026 | 20.048 ns | 0.0286 ns | 1.00 |
| LongPointers | 1026 | 63.347 ns | 0.1062 ns | 3.16 |
| Unrolled | 1026 | 39.175 ns | 0.0304 ns | 1.95 |
| PInvokeMemcmp | 1026 | 40.830 ns | 0.0350 ns | 2.04 |
| | | | | |
| SpansEqual | 1048585 | 44,070.526 ns | 35.3348 ns | 1.00 |
| LongPointers | 1048585 | 59,973.407 ns | 80.4145 ns | 1.36 |
| Unrolled | 1048585 | 55,032.945 ns | 24.4745 ns | 1.25 |
| PInvokeMemcmp | 1048585 | 55,593.719 ns | 22.4301 ns | 1.26 |
| | | | | |
| SpansEqual | 2147483591 | 253,648,180.000 ns | 1,112,524.3074 ns | 1.00 |
| LongPointers | 2147483591 | 249,412,064.286 ns | 1,079,409.5670 ns | 0.98 |
| Unrolled | 2147483591 | 246,329,091.667 ns | 852,021.7992 ns | 0.97 |
| PInvokeMemcmp | 2147483591 | 247,795,940.000 ns | 3,390,676.3644 ns | 0.98 |
我很惊讶地发现SpansEqual
max-array-size方法没有脱颖而出,但是差异是如此之小,以至于我认为这无关紧要。
我的系统信息:
BenchmarkDotNet=v0.12.0, OS=Windows 10.0.18362
Intel Core i7-6850K CPU 3.60GHz (Skylake), 1 CPU, 12 logical and 6 physical cores
.NET Core SDK=3.1.100
[Host] : .NET Core 3.1.0 (CoreCLR 4.700.19.56402, CoreFX 4.700.19.56404), X64 RyuJIT
DefaultJob : .NET Core 3.1.0 (CoreCLR 4.700.19.56402, CoreFX 4.700.19.56404), X64 RyuJIT