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