에서 이전 기사가 게시 된 후 블로그 게시물, 나는 .NET의 CORE에 두 개의 파일을 비교하는 가장 빠른 방법이 무엇인지 찾으려고 여러 가지 방법을 사용합니다., 보의 친구의 많은 논의를 불러 일으켰다, 나는 당신의 지원을 당신에게 표현 진심으로 감사합니다.
또한 거의 디스크 IO 속도의 한계를 넘어, 빠른 정상의 결과가 아니라고, 내가 지난 의심의 ReadOnlySpan 방법을 사용하여 보의 친구의 결과를 발표했다.이 점에서 나는 깊이에 반영하고자 ------ 내가 마지막 실행에 ReadOnlySpan, 그것은 디스크 캐시를 활용, 크게 비교의 속도를 가속 더 엄격하고 공정을 사용하여,이를 발견했을 때, 나는 즉시 보웬의 출시 전에 취소, 전체 테스트 프로그램을 재 설계 방법은 각 비교 방법을 테스트하고 곧바로 기록을 설정하는 블로그 포스트를 작성합니다.
또한, 의견의 재 테스트를 완벽하게 수행 보 친구의 과정에서 다음과 같은 사항 개선 :
모든 테스트는 사용 BenchmarkDotNet을 에
보다 전문적인 공정 결과를 들어, 사용 BenchmarkDotNet을 테스트하는 코드를 리팩토링
다른 캐시 크기를보십시오
완전히 상이한 속도에 대한 버퍼 크기의 효과를 테스트하기 위해, 바이트 어레이의 캐시 크기, 즉 세 종류로 나눌 :
- 4096 * 10
- 4096 * 100
- * 1000 4096
비동기 IO 방법을 사용해보십시오
비동기 IO의 속도에 미치는 영향을 관찰하기 위해
실행하기 전에 지우기 디스크 캐시
물론, 이것은이 여기에 가장 중요한 일을 게시하는 방법을 사용하는 것입니다 Win32API 각 디스크 캐시 (코드는 윈도우가 아닌 다른 플랫폼에서 실행해야하는 경우 자기 실현의 캐시를 지워야합니다, 코드의 실행 방법의 시작 부분에 텍스트를 볼 후 비교적 명확 )
비교 방법에 대한 원리를 참조 A의 단지 결과를 표시하지 여기를 반복 블로그 :
BenchmarkDotNet=v0.11.5, OS=Windows 10.0.18362
Intel Core i7-7700HQ CPU 2.80GHz (Kaby Lake), 1 CPU, 8 logical and 4 physical cores
.NET Core SDK=2.2.401
[Host] : .NET Core 2.2.6 (CoreCLR 4.6.27817.03, CoreFX 4.6.27818.02), 64bit RyuJIT
DefaultJob : .NET Core 2.2.6 (CoreCLR 4.6.27817.03, CoreFX 4.6.27818.02), 64bit RyuJIT
방법 | 버퍼 크기 | 평균 | 오류 | STDDEV | 중앙값 |
---|---|---|---|---|---|
CompareByMD5 | 40960 | 3.294의 | 0.0608의 | 0.0539의 | 3.311의 |
CompareByMD5Async | 40960 | 4.723의 | 0.0137의 | 0.0128의 | 4.720의 |
CompareByToInt64 | 40960 | 4.883의 | 0.0140의 | 0.0131의 | 4.886의 |
CompareByByteArray | 40960 | 4.713의 | 0.0059의 | 0.0052의 | 4.714의 |
CompareByByteArrayAsync | 40960 | 4.687의 | 0.0070의 | 0.0066의 | 4.688의 |
CompareByString | 40960 | 5.491의 | 0.1066의 | 0.0997의 | 5.483의 |
CompareBySequenceEqual | 40960 | 5.185의 | 0.1028의 | 0.1337의 | 5.180의 |
CompareByWin32API | 40960 | 4.334의 | 0.0209의 | 0.0195의 | 4.331의 |
CompareByReadOnlySpan | 40960 | 4.316의 | 0.0209의 | 0.0195의 | 4.313의 |
CompareByReadOnlySpanAsync | 40960 | 4.699의 | 0.0235의 | 0.0220의 | 4.695의 |
CompareByMD5 | 409600 | 3.329의 | 0.0639의 | 0.0808의 | 3.334의 |
CompareByMD5Async | 409600 | 4.727의 | 0.0192의 | 0.0179의 | 4.720의 |
CompareByToInt64 | 409600 | 4.881의 | 0.0111의 | 0.0104의 | 4.879의 |
CompareByByteArray | 409600 | 3.017의 | 0.0583의 | 0.0798의 | 3.014의 |
CompareByByteArrayAsync | 409600 | 3.038의 | 0.0935의 | 0.1370의 | 2.996의 |
CompareByString | 409600 | 5.086의 | 0.0871의 | 0.0815의 | 5.075의 |
CompareBySequenceEqual | 409600 | 5.019의 | 0.0978의 | 0.0915의 | 4.998의 |
CompareByWin32API | 409600 | 3.048의 | 0.1061의 | 0.1263의 | 3.017의 |
CompareByReadOnlySpan | 409600 | 3.079의 | 0.0862의 | 0.1264의 | 3.045의 |
CompareByReadOnlySpanAsync | 409600 | 2.976의 | 0.0484의 | 0.0452의 | 2.988의 |
CompareByMD5 | 4096000 | 3.456의 | 0.0850의 | 0.2410의 | 3.369의 |
CompareByMD5Async | 4096000 | 4.766의 | 0.0412의 | 0.0385의 | 4.762의 |
CompareByToInt64 | 4096000 | 5.003의 | 0.0789의 | 0.0659의 | 4.998의 |
CompareByByteArray | 4096000 | 2.558의 | 0.0505의 | 0.1055의 | 2.607의 |
CompareByByteArrayAsync | 4096000 | 2.500의 | 0.0492의 | 0.0766의 | 2.508의 |
CompareByString | 4096000 | 6.024의 | 0.0655의 | 0.0613의 | 6.020의 |
CompareBySequenceEqual | 4096000 | 4.949의 | 0.0793의 | 0.0742의 | 4.931의 |
CompareByWin32API | 4096000 | 2.582의 | 0.0511의 | 0.0881의 | 2.620의 |
CompareByReadOnlySpan | 4096000 | 2.677의 | 0.0503의 | 0.0420의 | 2.666의 |
CompareByReadOnlySpanAsync | 4096000 | 2.460의 | 0.0492의 | 0.0657의 | 2.458의 |
바이트 "Buffers_size"배열 버퍼 크기이며 그
시간이 평균적으로 소비하는 "평균"열, 낮은, 더 나은
내가 파일 크기를 테스트 이번에는 우리가 다음과 같은 동작을 관찰 할 수있는 데이터에서, 500메가바이트입니다 :
CompareByMD5
바이트 배열 버퍼와 같은 방법은 사용되지 않고, 그래서 심지어 빠른 방법으로 실질적으로 안정 각 군의 시험 결과를 40,960 설정된CompareByString
모든 그룹에서 최악의, 두 번째 차이가 있다는 것입니다CompareBySequenceEqual
내가 인센티브가 없다, 그래서 그들을 비동기 방법을 쓰기 위해,- 바이트 배열 캐시 방법은 실질적으로 빠른 캐시로 증가한다.
- 가장 큰 그룹이 결과를이기는 시작 캐시에 비동기 방식 (409600)는 의미는, 전반적으로 좋은 것이 아니라,
CompareByReadOnlySpan
이 블로그 게시물에 또한 뛰어난 성능,하자 오해는 마음의 평화를 많이 만들어CompareByByteArray
각 그룹에서 거의 확실히 경쟁력CompareByReadOnlySpan
디스크 캐시가 칠 때. 그러나, 목, 목CompareByReadOnlySpan
개방 매달려처럼 이륙 같은 속도 일 것이다.CompareByWin32API
그것은 또한 아주 좋은,하지만 Windows 플랫폼에서 사용할 수 있습니다
결론 :
- 가장 간단한 MD5이며, 속도는 허용
- 가장 간단하게는이 ByteArray, 이해하기 쉬운 코드, 좋은 속도
- 가장 실용적인 것은
CompareByReadOnlySpan
, 속도도 디스크 캐시의 사용 좋지만,
代码放在GITHUB上, 其中清除磁盘的缓存需要管理员权限, 所以需要以管理员权限运行Visual Studio
关于文件比较的方法希望通过这篇博文能得到正确的结论了, 也欢迎广大博友积极评论!