.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

关于文件比较的方法希望通过这篇博文能得到正确的结论了, 也欢迎广大博友积极评论!

转载于:https://www.cnblogs.com/waku/p/11447819.html