当我在文件系统中读取一个大文件时，缓存可以提高速度 手术？
我认为有两种不同的答案：
1.是。因为缓存可以预取，因此性能得到改善。
2.No。因为从缓存读取的速度比读取速度更快 磁盘，最后我们可以发现缓存没有帮助，所以读取速度也是如此 从磁盘读取的速度。
哪一个是正确的？我怎样才能证实答案？
[编辑]
另一个问题是：
我不确定是什么 当你打开缓存时，带宽用于
1.prefetch
2.prefetch and read
哪一个是正确的？
如果你 关闭缓存，磁盘带宽只是用来读取。
如果我关闭缓存并随机访问磁盘，所需的时间是否与打开缓存时按顺序读取的时间相当？
答案 0 :(得分：4)
1绝对是正确的。当您的代码处理已经收到的数据时，操作系统可以从磁盘提取到缓存。是的，磁盘可能仍然是瓶颈 - 但您不会阅读，处理，读取，处理，读取，处理，而是读取+处理，读取+处理，读取+处理。例如，假设我们的处理时间只占阅读时间的一半。代表页面上的时间，我们可能没有预取这种活动：
Read
Read
Process
Read
Read
Process
Read
Read
Process
虽然预取，但优化为：
Read
Read
Read Process
Read
Read Process
Read
Process
基本上总时间将是“读取整个文件的时间+处理最后一段数据的时间”，而不是“读取整个文件的时间+处理整个文件的时间”。
测试它很棘手 - 您需要一个可以调整或关闭缓存的操作系统。另一种方法是更改打开文件的方式 - 例如，在.NET中，如果使用FileOptions.SequentialScan打开文件，则缓存更有可能做正确的事情。尝试使用和不使用该选项。
这主要讲的是预取 - 一般缓存（即使在将数据传送到应用程序之后保留数据）也是另一回事，如果你想多次使用相同的数据，这显然是一个巨大的胜利。还有“介于两者之间”的应用程序只需要少量数据，但是磁盘已经读取了整个块 - 操作系统没有主动预取未被请求的块，但可以缓存整个块如果应用程序然后从同一个块请求更多数据，它可以从缓存中返回该数据。
答案 1 :(得分：3)
第一个答案是正确的。
磁盘具有固定的基础性能 - 但固定的基础性能在不同情况下有所不同。当您阅读长段数据时，您可以从驱动器获得更好的实际性能 - 例如当你向前缓存时。因此，缓存允许驱动器真正改善其实际性能。
答案 2 :(得分：3)
在一般情况下，缓存会更快。需要考虑的一些要点：
磁盘上的数据按表面（也称为磁头），磁道和块进行组织。磁盘需要一些时间来定位读取头，以便您可以开始读取轨道。现在你需要距离该轨道五个街区。不幸的是，你要求的顺序与它们在物理媒体上出现的顺序不同。通过将整个轨道读入内存（比你需要的更多的块），缓存将有很大帮助，然后重新索引它们（当磁头开始读取时，它可能在轨道上的任何地方，而不是第一个块的开始）。如果没有这个，你必须等到轨道的第一个块在头部下方旋转并开始读取 - ＆gt;阅读轨道的时间实际上会翻倍。因此，使用缓存，您可以按任何顺序读取轨道的块，并在磁头到达轨道时立即开始阅读。
如果文件系统已满，操作系统将开始将数据压缩到各种空白区域。想象一下块1在轨道5上，块2在轨道7上，块3再次在轨道5上。没有缓存，你将花费大量时间来定位头部。使用缓存时，轨道5被读取，当磁头进入第7轨道时保存在RAM中，当你要求第3块时，你会立即得到它。
大文件需要大量的元数据，即文件的数据块。在这种情况下，缓存会在您阅读文件时保持此数据的实时性，从而避免您遭受更多麻烦。
当您占用磁盘时，缓存将允许其他程序以有效的方式访问其数据。所以整体表现会更好。当您阅读时第二个程序开始写时，这非常重要。在这种情况下，缓存将在中断读取之前收集一些写入。此外，大多数程序读取数据，处理它然后再写回来。如果没有缓存，程序将会以自己的方式进行，或者必须实现自己的缓存方案以避免头部混乱。
缓存允许操作系统重新排序磁盘I / O.假设您在第5,7和13号轨道上有块，但是文件顺序要求轨道5,13和7。显然，在前往13的路上读取轨道7而不是一直到13然后再回来更有效率到7。
因此，理论上，在没有缓存的情况下读取大量数据会更快，只有当您的文件是磁盘上的唯一文件并且所有元数据都完美排序时，才会出现这种情况，数据的物理布局就是这样的阅读头总是在第一个块的开头读取轨道等的方式
答案 3 :(得分：1)
Jon Skeet有一个关于此主题的very interesting benchmark。基本结果是预取有所帮助，每单元读取的处理次数就越多。
答案 4 :(得分：0)
如果文件大于你的记忆，那肯定无法帮助。
答案 5 :(得分：0)
另一点：机会是，经常使用的文件将在一个甚至开始读取其中一个之前在缓存中。