2

我有一些非常慢的代码。我知道它会是，现在它是。基本上，我正在从一堆目录中读取文件。文件名改变，但数据不变。为了确定我是否已读取该文件，我对它的字节进行哈希处理并将其与已处理文件的哈希列表进行比较。每个目录中大约有 1000 个文件，弄清楚每个目录中的新内容需要花费一分钟左右的时间（然后开始处理）。这是基本代码：

public static class ProgramExtensions
{
    public static byte[] ToSHA256Hash(this FileInfo file)
    {
        using (FileStream fs = new FileStream(file.FullName, FileMode.Open))
        {
            using (SHA256 hasher = new SHA256Managed())
            {
                return hasher.ComputeHash(fs);
            }
        }
    }
    public static string ToHexString(this byte[] p)
    {

        char[] c = new char[p.Length * 2 + 2];

        byte b;

        c[0] = '0'; c[1] = 'x';

        for (int y = 0, x = 2; y < p.Length; ++y, ++x)
        {
            b = ((byte)(p[y] >> 4));

            c[x] = (char)(b > 9 ? b + 0x37 : b + 0x30);

            b = ((byte)(p[y] & 0xF));

            c[++x] = (char)(b > 9 ? b + 0x37 : b + 0x30);
        }

        return new string(c);

    }
}

class Program
{
    static void Main(string[] args)
    {
        var allFiles = new DirectoryInfo("c:\\temp").GetFiles("*.*");

        List<string> readFileHashes = GetReadFileHashes();

        List<FileInfo> filesToRead = new List<FileInfo>();

        foreach (var file in allFiles)
        {
            if (readFileHashes.Contains(file.ToSHA256Hash().ToHexString()))
                filesToRead.Add(file);
        }

        //read new files
    }
}

无论如何我可以加快速度吗？

4

7 回答 7

8

我相信您可以通过简单地首先检查文件大小来存档最显着的性能改进，如果文件大小不匹配，您可以跳过整个文件甚至不打开它。

除了保存已知哈希列表之外，您还可以保留已知文件大小的列表，并且仅在文件大小匹配时进行内容比较。当文件大小不匹配时，您甚至可以避免查看文件内容。

根据您的文件通常具有的一般大小，可能值得进一步改进：

  • 在第一个字节不同时与早期中止进行二进制比较（保存读取整个文件，如果您的文件通常很大，这可能是一个非常显着的改进，任何哈希算法都会读取整个文件。检测到第一个字节不同使您免于阅读文件的其余部分）。如果您的查找文件列表可能包含许多相同大小的文件，那么您可能必须对多个文件进行二进制比较，而不是考虑：

  • 散列在每个 1MB 的块中。首先仅根据查找中预先计算的第一个块哈希检查第一个块。如果第一个块相同，则仅比较第二个块，在大多数情况下为不同的文件保存超过第一个块的读取。只有当您的文件很大时，这两个选项才真正值得付出努力。

我怀疑更改散列算法本身（例如，按照建议首先检查执行 CRC）会产生任何显着差异。您的瓶颈可能是磁盘 IO，而不是 CPU，因此避免磁盘 IO 会给您带来最大的改进。但一如既往地在性能方面进行衡量。

然后，如果这仍然不够（仅此而已），请尝试异步 IO（请记住，尽管顺序读取通常比随机访问快，因此过多的随机异步读取会损害您的性能）

于 2009-06-09T21:52:24.073 回答
1

  • 为您的 readFileHashes 存储使用具有高效搜索能力（散列或二进制搜索）的数据结构。我认为 HashSet 或 TreeSet 会在这里为您提供更好的服务。

  • 使用适当的校验和（哈希和）函数。SHA256 是一种加密散列，可能有点矫枉过正。CRC 的计算成本较低，最初用于捕获无意/随机更改（传输错误），但容易受到设计/旨在隐藏的更改的影响。什么适合您正在扫描的文件之间的差异？

    请参阅http://en.wikipedia.org/wiki/List_of_checksum_algorithms#Computational_costs_of_CRCs_vs_Hashes

    通过采样的非常简单的校验和（例如校验和 =（前 10 个字节和后 10 个字节））是否有效？

于 2009-06-09T22:15:15.353 回答
1
  • 创建文件列表
  • 按文件大小对列表进行排序
  • 从列表中删除具有唯一大小的文件
  • 现在做散列（首先快速散列也可以提高性能）
于 2009-06-09T21:53:35.850 回答
0

更新：绝对不要只检查文件大小。如果您的操作系统版本允许使用 FileInfo.LastWriteTime

我已经为内部项目编译器/打包器实现了类似的东西。我们有超过 8k 个文件，因此我们将最后修改的日期和哈希数据存储到 sql 数据库中。然后在随后的运行中，我们首先查询任何特定文件的修改日期，然后才查询哈希数据......这样我们只计算那些似乎被修改的文件的新哈希数据......

.net 有一种方法可以在 FileInfo 类中检查上次修改日期。我建议你检查一下。编辑：这是链接LastWriteTime

我们的打包程序需要大约 20 秒来找出哪些文件已被修改。

于 2009-06-09T23:22:59.400 回答
0

您对问题的描述仍然不够清楚。

最大的问题是你正在做一堆散列。这保证很慢。

您可能想尝试搜索修改时间，如果文件名更改，该时间不会更改：

http://msdn.microsoft.com/en-us/library/ms724320(VS.85,loband).aspx

或者您可能想要监视文件夹是否有任何新文件更改：

http://www.codeguru.com/forum/showthread.php?t=436716

于 2009-06-09T22:13:32.690 回答
0

我会先做一个快速的 CRC 哈希检查，因为它更便宜。如果 CRC 不匹配，则继续进行更“可靠”的哈希测试，例如 SHA

于 2009-06-09T21:47:19.110 回答
0

首先按文件大小对文件进行分组 - 这将为您留下较小的文件组。现在它取决于组大小和文件大小。您可以开始并行读取所有文件，直到找到不同之处。如果存在差异，请将组拆分为在当前位置具有相同值的较小组。如果您了解文件的不同之处，则可以使用此信息 - 从最后开始阅读，如果更大的集群发生变化，或者您对文件的了解如何，请不要逐字节读取和比较。如果您必须并行读取许多文件导致随机磁盘访问，此解决方案可能会引入 I/O 性能问题。

您还可以计算每个组中所有文件的哈希值并进行比较。您不必一次处理整个文件 - 只需计算几个（可能是 4kiB 集群或任何适合您的文件大小）字节的哈希值并检查是否存在差异。如果不是，请计算接下来几个字节的哈希值。这将使您能够处理每个文件的较大块，而无需为内存中的组中的每个文件保留一个这样的大块。

所以这都是关于时间内存（磁盘 I/O 内存）的权衡。您必须在将组中的所有文件读入内存并逐字节比较它们（高内存要求，快速顺序访问，但可能读取大量数据）和逐字节读取文件并仅比较最后一个字节之间找到自己的方法读取（内存要求低，随机访问速度慢，只读取所需的数据）。此外，如果组非常大，逐字节比较文件会变得更慢 - 比较 n 个文件中的一个字节是 O(n) 操作 - 首先计算哈希值然后只比较哈希可能会变得更有效价值观。

于 2009-06-09T22:33:28.000 回答