这不是纯粹的编程问题,但它会影响使用fseek()函数的程序性能,因此了解其工作原理非常重要。为避免被关闭,先声明一下。
我想知道在文件中间插入数据的效率如何。假设我有一个1MB大小的文件,然后我在512KB的偏移处插入一些内容,与将我的数据附加到文件末尾相比,这样做的效率如何?为了使示例完整,假设我想插入16KB的数据。
我知道答案会因文件系统而异,但我认为常见文件系统使用的技术相当相似,我只是想获得正确的概念。
这不是纯粹的编程问题,但它会影响使用fseek()函数的程序性能,因此了解其工作原理非常重要。为避免被关闭,先声明一下。
我想知道在文件中间插入数据的效率如何。假设我有一个1MB大小的文件,然后我在512KB的偏移处插入一些内容,与将我的数据附加到文件末尾相比,这样做的效率如何?为了使示例完整,假设我想插入16KB的数据。
我知道答案会因文件系统而异,但我认为常见文件系统使用的技术相当相似,我只是想获得正确的概念。
fseek(...)
是一个库调用,而不是操作系统系统调用。从技术上讲,运行时库负责处理调用操作系统的实际开销,间接地说,fseek(...)
间接地调用了系统,但实际上并没有(这引出了库调用和系统调用之间的明显区别)。 无论底层系统如何,fseek(...)
都是标准的输入输出函数...然而...这是非常大的“however”...
操作系统很可能已经将文件缓存在其内核内存中,也就是在磁盘上存储1和0的位置的直接偏移量,很可能是在内核中的最高层中拥有关于文件组成的快照,即数据,而不管它包含什么(只要该偏移量指向磁盘上的有效结构!)...
当发生fseek(..)
时,会有很多开销,间接地,内核委托了从磁盘读取的任务,具体取决于文件的碎片情况,从用户空间的角度来看,也就是C代码执行fseek(...)
,它可能会分散在各处,以收集数据并插入到文件中的"连续数据"中。因此,在文件中插入到中间位置(记住在此阶段,内核必须调整到实际磁盘盘片上的数据偏移量)将被认为比追加到文件末尾慢。
原因很简单,内核“知道”最后一个偏移量是什么,并简单地抹去EOF标记并插入更多数据。在幕后,内核必须为具有调整偏移量的磁盘缓冲区分配另一个内存块,以跟随EOF标记的位置。完成数据的追加后。
如果数据大小是FS扇区的倍数,那么您只能有效地将数据插入到文件中间,但操作系统不提供这样的功能,因此您必须使用低级接口来访问FS驱动程序。