代码之家  ›  专栏  ›  技术社区  ›  dicroce

为什么fseeko()处理大文件比处理小文件快?

  •  4
  • dicroce  · 技术社区  · 15 年前

    我在这里得到了一些奇怪的性能结果,我希望stackoverflow.com上的人能对此有所帮助!

    首先,我通过dd'ing/dev/zero创建了两个文件来分隔文件。。。一个是1MB,另一个是9.8gb。。。然后我写了这个代码:

    #define _LARGE_FILE_API
    #define _FILE_OFFSET_BITS 64
    
    #include <stdio.h>
    #include <stdlib.h>
    #include <sys/stat.h>
    #include <sys/types.h>
    #include <unistd.h>
    
    int main( int argc, char* argv[] )
    {
      struct stat64 fileInfo;
      stat64( argv[1], &fileInfo );
    
      FILE* inFile = fopen( argv[1], "r" );
    
      for( int i = 0; i < 1000000; i++ )
        {
          double seekFrac = ((double)(random() % 100)) / ((double)100);
    
          unsigned long long seekOffset = (unsigned long long)(seekFrac * fileInfo.st_size);
    
          fseeko( inFile, seekOffset, SEEK_SET );
        }
    
        fclose( inFile );
    }
    

    基本上,这段代码在整个文件范围内进行一百万次随机搜索。当我在time下运行时,对于smallfile会得到如下结果:

    [developer@stinger ~]# time ./seeker ./smallfile
    
    real    0m1.863s
    user    0m0.504s
    sys  0m1.358s
    

    当我对9.8 gig文件运行它时,得到如下结果:

    [developer@stinger ~]# time ./seeker ./bigfile
    
    real    0m0.670s
    user    0m0.337s
    sys  0m0.333s
    

    2 回复  |  直到 15 年前
        1
  •  15
  •   Carl Smotricz    15 年前

    你不是在衡量磁盘性能,而是在衡量它需要多长时间 fseek 设置指针并返回。

        2
  •  0
  •   advait    15 年前

    我认为这与执行 fseeko .

    的手册页 fseek 表示它只是“为指定的流设置文件位置指示符”。由于设置整数应该与文件大小无关,因此可能存在一个“优化”,它将在fseek之后对小文件而不是大文件执行自动读取(并缓存结果信息)。