.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

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

你可能感兴趣的:(.NET CORE下最快比较两个文件内容是否相同的方法 - 续)