DED*_*DED 5 arrays seek hard-drive sequential
假设在硬盘驱动器上有一些非常大的字符序列数据文件：
阿布德兹....
我的问题如下，如果头部位于文件的开头，并且我每 1000 个位置间隔需要 5 个字符，那么最好是进行 Seek （因为我知道在哪里查找）或者只是拥有一个大缓冲区只是按顺序读取然后在内存中完成工作。
我天真地回答说，读取“A”然后寻求读取“V”比>>读取所有文件直到位置200（“V”的位置）更快。好吧，这只是一个例子，因为最小的 I/O 是 512 字节。
编辑：我之前的自我天真的答案在一定程度上是由以下情况证明的：给定一个 100Gb 文件，我需要第一个和最后一个字符；在这里我显然会寻求......对吧？
也许在查找“多长时间”与检索多少数据之间需要权衡？
有人可以向我澄清这一点吗？
[更新] 一般来说，如果您的步数小于您的块大小的 2 倍，则每 1000 个中的 5 个（我假设 5 个字节是 1000 的一部分，从而使您的步数为 1000）答案是一个很好的解释。一旦你超过 2 倍的 HD 块大小，它确实会变得有点棘手，因为在这一点上，你很容易浪费读取时间，而你可以通过寻找过去未使用的（或者就此而言不必要的）来加快速度。 ) 高清块。
[原文] 嗯，这是一个非常有趣的问题，我认为这是一个同样有趣的答案（也有些复杂）。我认为实际上这取决于其他几个问题，例如您在驱动器（或您的软件将在其上运行的驱动器）上实现的块大小有多大。如果您的块大小为 4KB，那么您的硬盘一次所能获得的（真实）最小值为 4096 字节。在您的情况下，如果您确实每 1000 个字符需要 5 个字符，那么如果您使用所有磁盘 IO 执行此操作，那么您实际上将重新读取同一块 4 次，并在中间执行 3 次查找（确实效率不高）。
我个人的信念是，您可以（如果您想提高驱动器效率）在代码中尝试了解您正在使用的驱动器的块大小是多少，然后使用该大小数字来了解您一次有多少字节应该带入RAM。这样，您就不必拥有巨大的 RAM 缓冲区，但同时也不必真正进行 SEEK，也不会浪费（或执行）任何额外的读取。
这是最有效的吗？我不认为它是最有效的，但它可能足以满足您所需的性能，谁知道呢。我确实认为，即使读取头位于您想要的位置，如果您在每个块读取的中间执行算法工作，而不是一次读取整个文件，那么您将浪费时间等待驱动器盘片的下一次旋转。然而，如果您要一次读取全部内容，则驱动器应该能够一次顺序读取文件的所有部分。不过，情况又不那么简单，就好像您的文件确实超过 1 个块一样，在旋转驱动器上，如果您的驱动器尚未进行碎片整理，您可能会遇到麻烦，因为它可能必须执行随机搜索才能到达下一个块。
抱歉，对于冗长的答案，但与往常一样，您的情况没有简单的答案。
我确实认为，如果您一次读取整个文件，整体性能可能会更好。没有办法保证这一点，因为每个系统的驱动器设置参数都有本质上的不同，等等......