fseek 的性能开销是多少？答案

【问题标题】：What is the performance overhead for fseek?fseek 的性能开销是多少？
【发布时间】：2017-09-27 01:40:51
【问题描述】：

fseek 是否有任何性能开销？例如，fseek 调用是否实际上要求内核移动磁盘头？

另外，fseek 性能成本是否与它所寻求的“距离”有什么关系？例如，fseek(1byte) 与fseek(100Mb) 与fseek（文件结束）。

【问题讨论】：

这真的取决于底层。文件系统、物理介质等。实际上它不需要做任何事情，除了改变内存中的一些数字。之后的实际读/写才是最重要的。
它很可能可以忽略不计，与寻求距离无关，但您不会得到任何明确的答案。你能做的最好的就是自己测量它，即使那样，你也不能保证你将在你的系统上测量的东西会接近你在另一个系统中测量的东西。（但它很可能普遍可以忽略不计。无论距离如何。）
在几乎所有类型的设备上，开销都可以忽略不计。
当然，磁盘磁头只会移动到尚未缓冲/缓存的实际读取。如果您在没有实际读取的情况下发出多个fseek 指令，为什么磁盘磁头会移动？
fseek() 调用存在隐含成本 - 如果 FILE * 处于写入模式，则与受影响的 FILE * 关联的任何缓冲区都可能会被刷新，如果处于读取模式，则可能会失效。 IO 模式（例如随机小读取）可能会导致显着的额外读取开销，因为每个fseek()/read 周期都会重新填充缓冲区。 fseek() 的“距离”和性能影响可能很重要，也可能不重要。这将取决于页面缓存命中以及磁盘磁头必须移动的距离。这取决于很多很多事情。

【解决方案1】：

与往常一样，了解事物如何影响性能的唯一方法是对其进行测试。但这里有一些一般性的陈述：

fseek 有性能开销吗？

一切都有性能开销。大多数事情只有很小的性能开销。如果您调用 fseek 并且内核或库已提前读取（读取的文件比您要求的更多），那么它很可能会丢弃预读数据，因为它位于错误的位置。

例如，fseek 调用实际上是否要求内核移动磁盘头？

不，它没有。它只是更新内核下次读取文件时将从中读取的位置。在您读取文件之前，硬盘不会执行任何操作。

下次访问文件时，磁头可能需要移动，也可能不需要移动。但它可能必须移动无论如何，即使你不使用fseek，因为文件可能是碎片化的，或者因为另一个程序访问了磁盘不同部分上的不同文件。 p>

它也可以以另一种方式工作。如果您要查找的文件部分恰好在缓存中（因为之前有访问过它），内核可以从缓存中获取它，而根本不必访问硬盘驱动器。

当然，头部运动与 SSD 或 tmpfs 中的文件等无关。

另外，fseek 性能成本是否与它寻求的“距离”有什么关系？例如，fseek(1byte) 与fseek(100Mb) 与fseek（文件结束）。

可能不多。

【讨论】：

它只是更新内核下次读取文件时将从中读取的位置。 如果目标位置为fseek() 调用位于任何用户空间缓存中，其中包含与 FILE * 关联的已读取数据。