并行文件是否比顺序读取更快？
我只是想知道是并行File.Read使用PLINQ / Parallel可以更快吗？ 我的代码如下（.Net 4.0）：
public static void ReadFileParallel(List fileName) { Parallel.Foreach(fileName, file=>File.Read(file)); } public static void ReadFilePLINQ(List fileName) { fileName.AsParallel().foreach(file=>File.Read(file)); }
我问这个的原因是因为我认为文件读取是IO绑定的，所以做并行不会有帮助，我是对的吗？
这取决于。
如果您的文件位于不同的位置，不同的网络共享或不同的物理硬盘驱动器上，那么是的，并行加载可能会有所帮助。 如果它们位于单个旋转硬盘驱动器上，并行读取文件可能会显着损害您的性能，因为这些并行读取可能会产生额外的搜索时间。
如果您的文件位于SSD上，您的性能可能略低，但这取决于您并行读取的文件数量以及它们的大小。 我想，在某个文件大小阈值和并行读取数量下，性能将显着下降。 没有一些实验就很难说出那个。
你是这么认为的，但这不是测量结果所显示的。 当文件I / O具有显着的延迟时，特别是在网络上，并行执行可以保持管道填充。
MSFT提供了一个优秀的PDF，详细介绍了并行和线程的可能性。
它可能有所帮助。
对于第一个近似值，如果文件位于不同的磁盘上，则会有所帮助，否则会使速度变慢（由于搜索时间增加）。
如果所有文件都被缓存，可能会稍快一些（因为您可以使用多个核心）。
当然，最好的选择是运行一些基准测试。
你并没有完全做一个并行File.Read，你正在并行执行多个File.Reads。 如果文件位于不同的主轴中，则只需一次使用多个主轴即可获得更高的吞吐量。
即使您使用单个主轴，如果每个Read都跟随CPU绑定处理，您也可以体验到改进的性能，尽管在这种情况下，安装Tasks对象会更好。 在这种情况下，您可以让一些任务从文件加载数据，而其他任务使用已加载的数据来执行一些繁重的处理。
我认为你已经在这里砸到了头上。
一般情况下，并行操作总是受到资源耗尽以便并行运行操作的限制，但即便如此，在越来越多的并行线程上仍然会有递减的回报。
Jeff Atwood发布了一个有趣的图表，我将在后面添加这个图表，显示multithreading环境中多核处理器的收益递减。 当然这不完全一样。 但是让我们从这个想法来看，即使你在100个硬盘驱动器上有100个文件，某个地方的IO也会被压缩回一个通道，这将导致读取增加的一些减少。
我基本上试图说的是并行运行并不意味着它会大大加快，重要的是要考虑并行进程是如何实际执行的。
这是一件棘手的事情。 如果你做错了，磁盘头会来回移动，试图同时读取两个文件。 这对于较大的文件尤其是一个问题。
但是，如果你并行读取了很多小文件，你可能会获得一点点因为磁盘子系统可以选择以不同于你要求的顺序读取文件。 但是，我没有在现实生活中看到这种效果。
您对内容的处理也可以与读取文件并行完成。 因此，您需要在发货前进行配置和基准测试。