4

私はここでいくつかの奇妙なパフォーマンス結果を得ています、そして私はstackoverflow.comの誰かがこれにいくつかの光を当てることができることを望んでいます！

私の目標は、大きなシークが小さなシークよりも高価であるかどうかをテストするために使用できるプログラムでした...

最初に、/ dev /zeroを追加してファイルを分離することで2つのファイルを作成しました...1つは1mb、もう1つは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 );
}

基本的に、このコードはファイルの全範囲にわたって100万回のランダムシークを実行します。これを時間内に実行すると、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倍以上の速度です。なんで？

4

2 に答える 2

15

ディスクのパフォーマンスを測定しているのではなくfseek、ポインタを設定して戻るのにかかる時間を測定しているのです。

実際のIOをテストする場合は、目的の場所からファイルを読み取ることをお勧めします。

于 2010-07-16T17:18:00.607 に答える
0

私はそれがの実装に関係していると思いますfseeko。

のマニュアルページはfseek、単に「指定されたストリームのファイル位置インジケータを設定する」ことを示しています。整数の設定はファイルサイズとは無関係である必要があるため、大きなファイルではなく小さなファイルのfseekの後に、自動読み取りを実行する（そして結果の情報をキャッシュする）「最適化」があるかもしれません。

于 2010-07-16T18:01:38.130 に答える