.NET CORE下最快比较两个文件内容是否相同的方法 - 续
在上一篇博文中, 我使用了几种方法试图找到哪个是.NET CORE下最快比较两个文件的方法.文章发布后,引起了很多博友的讨论, 在此我对大家的支持表示由衷的感谢.
其中也有博友提出了对于我最后使用ReadOnlySpan的方法的结果的怀疑, 认为它的结果快的不正常, 几乎超出了磁盘IO速度的限制. 对此我要深刻的进行反省------我把ReadOnlySpan放在最后执行,使它利用了磁盘缓存,而大大加快了比较速度, 当发现这点时,我立即取消发布了之前的博文,并重新设计了整个测试方案, 使用更严谨公平的方式测试每个比较方法, 并写下此篇博文以正视听.
另外, 在重新测试的过程中, 也充分采取了博友的意见, 改进了以下几点:
-
全部测试使用BenchmarkDotNet来进行
为了更专业公平的结果, 重构代码使用BenchmarkDotNet来测试
-
尝试不同缓存大小
为了充分测试不同缓存大小对速度的影响, 字节数组的缓存大小分为3种, 分别是:
- 4096 * 10
- 4096 * 100
- 4096 * 1000
-
尝试使用异步IO方法
以观察异步IO对速度的影响
-
运行前清除磁盘缓存
当然这是本篇博文最重要的一点. 这里利用了Win32API在每个比较方法运行开始时清除磁盘缓存(代码见文后,如果代码需要在Windows以外的平台上运行, 需要自行实现清除缓存的方法)
关于比较方法的原理请参看上一篇博文,这里就不再赘述, 只是展示结果:
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
| Method | buffer_size | Mean | Error | StdDev | Median |
|---|---|---|---|---|---|
| CompareByMD5 | 40960 | 3.294 s | 0.0608 s | 0.0539 s | 3.311 s |
| CompareByMD5Async | 40960 | 4.723 s | 0.0137 s | 0.0128 s | 4.720 s |
| CompareByToInt64 | 40960 | 4.883 s | 0.0140 s | 0.0131 s | 4.886 s |
| CompareByByteArray | 40960 | 4.713 s | 0.0059 s | 0.0052 s | 4.714 s |
| CompareByByteArrayAsync | 40960 | 4.687 s | 0.0070 s | 0.0066 s | 4.688 s |
| CompareByString | 40960 | 5.491 s | 0.1066 s | 0.0997 s | 5.483 s |
| CompareBySequenceEqual | 40960 | 5.185 s | 0.1028 s | 0.1337 s | 5.180 s |
| CompareByWin32API | 40960 | 4.334 s | 0.0209 s | 0.0195 s | 4.331 s |
| CompareByReadOnlySpan | 40960 | 4.316 s | 0.0209 s | 0.0195 s | 4.313 s |
| CompareByReadOnlySpanAsync | 40960 | 4.699 s | 0.0235 s | 0.0220 s | 4.695 s |
| CompareByMD5 | 409600 | 3.329 s | 0.0639 s | 0.0808 s | 3.334 s |
| CompareByMD5Async | 409600 | 4.727 s | 0.0192 s | 0.0179 s | 4.720 s |
| CompareByToInt64 | 409600 | 4.881 s | 0.0111 s | 0.0104 s | 4.879 s |
| CompareByByteArray | 409600 | 3.017 s | 0.0583 s | 0.0798 s | 3.014 s |
| CompareByByteArrayAsync | 409600 | 3.038 s | 0.0935 s | 0.1370 s | 2.996 s |
| CompareByString | 409600 | 5.086 s | 0.0871 s | 0.0815 s | 5.075 s |
| CompareBySequenceEqual | 409600 | 5.019 s | 0.0978 s | 0.0915 s | 4.998 s |
| CompareByWin32API | 409600 | 3.048 s | 0.1061 s | 0.1263 s | 3.017 s |
| CompareByReadOnlySpan | 409600 | 3.079 s | 0.0862 s | 0.1264 s | 3.045 s |
| CompareByReadOnlySpanAsync | 409600 | 2.976 s | 0.0484 s | 0.0452 s | 2.988 s |
| CompareByMD5 | 4096000 | 3.456 s | 0.0850 s | 0.2410 s | 3.369 s |
| CompareByMD5Async | 4096000 | 4.766 s | 0.0412 s | 0.0385 s | 4.762 s |
| CompareByToInt64 | 4096000 | 5.003 s | 0.0789 s | 0.0659 s | 4.998 s |
| CompareByByteArray | 4096000 | 2.558 s | 0.0505 s | 0.1055 s | 2.607 s |
| CompareByByteArrayAsync | 4096000 | 2.500 s | 0.0492 s | 0.0766 s | 2.508 s |
| CompareByString | 4096000 | 6.024 s | 0.0655 s | 0.0613 s | 6.020 s |
| CompareBySequenceEqual | 4096000 | 4.949 s | 0.0793 s | 0.0742 s | 4.931 s |
| CompareByWin32API | 4096000 | 2.582 s | 0.0511 s | 0.0881 s | 2.620 s |
| CompareByReadOnlySpan | 4096000 | 2.677 s | 0.0503 s | 0.0420 s | 2.666 s |
| CompareByReadOnlySpanAsync | 4096000 | 2.460 s | 0.0492 s | 0.0657 s | 2.458 s |
"buffers_size"即是字节数组缓存的大小
"Mean"列即平均耗时, 数值越小越好
这次我测试的文件大小是500MB, 从数据中我们能观察到以下现象:
CompareByMD5方法因为未使用字节数组缓存,所以在各组测试中的结果基本稳定.甚至在40960组中是最快的方法CompareByString在所有组中表现最差, 第2差的是CompareBySequenceEqual, 所以我都没有动力为它们写异步方法- 使用字节数组缓存的方法, 基本上是随着缓存的增大, 速度越快.
- 异步方法在缓存最大那组(409600)中才开始有胜出的结果, 不过整体来看意义并不大
CompareByReadOnlySpan同样表现优异, 这让我对上一篇博文中犯的错安心了很多CompareByByteArray在各组中都相当有竞争力, 几乎与CompareByReadOnlySpan并驾齐驱.不过当命中磁盘缓存时,CompareByReadOnlySpan会像开挂一样速度起飞.CompareByWin32API也非常出色, 不过只能在Windows平台使用
结论:
- 最简单的是MD5, 速度也可以接受
- 最朴实的是ByteArray, 代码通俗易懂, 速度出色
- 最实用的还是
CompareByReadOnlySpan, 速度出色, 还可利用磁盘缓存
代码放在GITHUB上, 其中清除磁盘的缓存需要管理员权限, 所以需要以管理员权限运行Visual Studio
关于文件比较的方法希望通过这篇博文能得到正确的结论了, 也欢迎广大博友积极评论!
