如何使用多线程优化大文件中单词和字符的计数？

问题描述

我有一个大约 1 GB 的非常大的文本文件。

我需要计算单词和字符（非空格字符）的数量。

我已经编写了以下代码。

string fileName = "abc.txt";
long words = 0;
long characters = 0;
if (File.Exists(fileName))
{
    using (StreamReader sr = new StreamReader(fileName))
    {
        string[] fields = null;
        string text = sr.ReadToEnd();
        fields = text.Split(' ',StringSplitOptions.RemoveEmptyEntries);
        foreach (string str in fields)
        {
            characters += str.Length;
        }
        words += fields.LongLength;
    }

    Console.WriteLine("The word count is {0} and character count is {1}",words,characters);
}

有没有什么办法可以让线程更快，有人建议我使用线程，这样它会更快？

我在我的代码中发现了一个问题，如果字数或字符数大于 long 最大值，该问题将失败。

我编写此代码时假设只有英文字符，但也可以有非英文字符。

我特别在寻找与线程相关的建议。

解决方法

以下是如何使用并行性有效地解决对巨大文本文件的非空白字符进行计数的问题。首先，我们需要一种以流方式读取字符块的方法。本机 File.ReadLines 方法不会剪切它，因为文件容易只有一行。下面是一个方法，它使用 StreamReader.ReadBlock 方法抓取特定大小的字符块，并将它们作为 IEnumerable<char[]> 返回。

public static IEnumerable<char[]> ReadCharBlocks(String path,int blockSize)
{
    using (var reader = new StreamReader(path))
    {
        while (true)
        {
            var block = new char[blockSize];
            var count = reader.ReadBlock(block,block.Length);
            if (count == 0) break;
            if (count < block.Length) Array.Resize(ref block,count);
            yield return block;
        }
    }
}

有了这个方法，就可以很容易地使用 PLINQ 并行化字符块的解析：

public static long GetNonWhiteSpaceCharsCount(string filePath)
{
    return Partitioner
        .Create(ReadCharBlocks(filePath,10000),EnumerablePartitionerOptions.NoBuffering)
        .AsParallel()
        .WithDegreeOfParallelism(Environment.ProcessorCount)
        .Select(chars => chars
            .Where(c => !Char.IsWhiteSpace(c) && !Char.IsHighSurrogate(c))
            .LongCount())
        .Sum();
}

上面发生的事情是多个线程正在读取文件并处理块，但读取文件是同步的。通过调用 IEnumerator<char[]>.MoveNext 方法，一次只允许一个线程获取下一个块。这种行为不像纯粹的生产者-消费者设置，其中一个线程专用于读取文件，但实际上性能特征应该是相同的。这是因为此特定工作负载的可变性较低。解析每个字符块应该花费大约相同的时间。所以当一个线程读完一个块时，另一个线程应该在等待读取下一个块的列表中，导致组合读操作几乎是连续的。

使用 NoBuffering 配置的 Partitioner 以便每个线程一次获取一个块。如果没有它，PLINQ 将使用块分区，这意味着每个线程一次会逐渐请求越来越多的元素。在这种情况下，块分区不适合，因为单纯的枚举操作成本很高。

工作线程由 ThreadPool 提供。当前线程也参与处理。所以在上面的例子中，假设当前线程是应用的主线程，ThreadPool提供的线程数为Environment.ProcessorCount - 1。

您可能需要根据您的硬件功能调整 blockSize（越大越好）和 MaxDegreeOfParallelism 来微调操作。 Environment.ProcessorCount 可能太多，2 可能就足够了。

计算单词的问题要困难得多，因为一个单词可能跨越多个字符块。整个 1 GB 文件甚至可能包含一个单词。您可以尝试通过研究 source code 方法的 StreamReader.ReadLine 来解决此问题，该方法必须处理同类问题。提示：如果一个块以非空白字符结尾，而下一个块也以非空白字符开头，则肯定有一个单词被分成两半。您可以跟踪分成两半的字数，并最终从总字数中减去这个数字。

,

这是一个根本不需要多线程的问题！为什么？因为CPU远远快于磁盘IO！因此，即使在单线程应用程序中，程序也会等待从磁盘读取数据。使用更多线程意味着更多等待。 你想要的是异步文件IO。所以，这样的设计：-

main
  asynchronously read a chunk of the file (one MB perhaps),calling the callback on completion
  while not at end of file
    wait for asynchronous read to complete
    process chunk of data
  end
end

asynchronous read completion callback
  flag data available to process
  asynchronously read next chunk of the file,calling the callback on completion
end

,

您可能会在开头获取文件的长度。让它成为“S”（字节）。 然后，让我们取一些常量“C”。

执行C线程，让每个线程处理S/C长度的文本。 您可以一次读取所有文件并将其加载到您的内存中（如果您有足够的 RAM），或者您可以让每个线程读取文件的相关部分。

第一个线程将字节 0 处理到 S/C。 第二个线程将字节 S/C 处理为 2S/C。 等等。

在所有线程完成后，总结计数。

怎么样？