比较大的文本文件——比较哈希比使用文件的子集更快
本文关键字：比较 文件 子集 哈希比 文本 | 更新日期: 2023-09-27 18:10:31
假设我有两个据称相同的大(文本)文件，但我想确保。整个哈利波特系列的"成人"answers"儿童"版本也许……
如果全文的字符串表示形式太大而不能一次保存在内存中，是否会更快:
- a)对两个文件进行整体哈希，然后测试哈希是否相同
或
- b)读取每个文件的可管理块并比较它们，直到达到EOF或找到不匹配
换句话说，比较两个小哈希的便利性是否会被生成哈希所花费的时间所抵消?
我期待着几个"视情况而定"的答案，所以如果你想要一些假设来工作:
- 语言是c# in。net
- 文本文件每个3GB
- 哈希函数为MD5
- 最大'备用' RAM为1GB
-
MD5校验和会比较慢，因为你需要处理两个文件才能得到结果。你说你有3GB的文件，只有1GB的内存，你自己算算。
-
在字节块中检查它们实际上会更早地确定任何差异，也可以通过检查文件大小，文件长度等…
我选择选项2
选项A只有在您重用哈希(即有其他文件进行比较)以便计算哈希的成本不是一个因素时才有用…
否则我会选择B…
为了获得最大的速度，我将使用MemoryMappedFile实例和XOR内容-比较可以在第一次遇到差异时停止(即XOR操作返回!= 0)。关于内存消耗，您可以使用"移动窗口"(即通过调用CreateViewAccessor)，这将允许字面上处理tb大小的文件…
用一些基于LINQ的比较方法来测试XOR的性能甚至是值得的…并且总是从比较文件大小开始，这样可以避免不必要的计算…
假设您将来没有使用哈希信息(与其他文本进行比较，或在潜在的未来更改后检查)，那么有两种情况:A)文件是相同的B)文件不同
如果A，那么两种情况之间几乎没有区别。两者都涉及一次读取整个文件的一个块，并对每个字节进行计算/比较。与读取文件的工作相比，哈希的计算开销是最小的。
如果是B，那么您可能会在文件的第一页发现差异，此时您可以退出该进程。
因此，根据A和B的相对概率，似乎比较平均会更快。还要注意，您可以报告发生更改的位置，这在has场景中是无法做到的。