主页 / 问题 / 999597
Accepted
Rootware
Asked:2020-07-05 14:36:58 +0800 CST2020-07-05 14:36:58 +0800 CST

文件版本控制的哈希和

  • 772

有一个游戏客户端，其中有大约 2000 个文件，大小从几千字节到数百兆字节不等。所有文件都是二进制文件，即 没有文字。

客户端是我不时修改的，因此我通过启动器使用自己编写的版本控制来检查游戏客户端的完整性，并在必要时进行更新。出于这些目的，我使用文件的 md5 哈希和。由于 MD5 哈希计算了相当长的时间（！），我使用两种类型的验证 - 快速（所有重要文件）和完整。

历史上发生了这样的事情，出于某种原因，我从一开始就开始使用这个特殊的哈希。我听说并阅读了有关 Adler32 和 CRC32 算法的信息，但我不确定在我的情况下不会发生冲突，因为 有时差异是文件的一个字节，或者可能完全不同。

如果有人已经有为此类任务计算快速可靠的哈希和的经验，那么请告诉我一个更优化的算法，因为。目前，对客户端的全面检查大约需要 5-10 分钟（即磁盘上大约 11 GB 的数据），具体取决于计算机。

c#

1 个回答

  1. Best Answer

    所以，我进行了一系列测试，发现使用ReadAllBytes()哈希和来计算 MD5 并不是最好的选择。

    原始代码是：

    public static byte[] getFileHash(string path)
{
    using (MD5 md5 = MD5.Create())
    {
        return md5.ComputeHash(File.ReadAllBytes(path));
    }
}

    文件的完整分析耗时 4 分 6 秒。

    改成后ReadAllBytes()性能OpenRead()提升20%。

    public static byte[] getFileHash(string path)
{
    using (MD5 md5 = MD5.Create())
    {
        return md5.ComputeHash(File.OpenRead(path));
    }
}

    最后一个选项在 3 分 10 秒内执行分析。

    PS HDD -> HDD with Sata 2 interface. 分析过程在一个线程中进行。我认为在多线程中，如果硬件配置更好，您仍然可以省钱。

    PPS 如评论中未订阅，算法本身不影响性能。一切都取决于读取文件本身的方法和可能性。

    • 1

相关问题