如何解决如何使用多线程优化大文件中单词和字符的计数?
我有一个大约 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。 等等。
在所有线程完成后,总结计数。
怎么样?
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。