「wc -l」よりも高速なものが必要

1GBのような非常に大きなファイルのwc -l場合、遅くなることがあります。特定のファイルの改行の数を計算するより速い方法はありますか？

あなたはCで書くことを試みることができます：

#include <unistd.h>
#include <stdio.h>
#include <string.h>
int main(){
  char buf[BUFSIZ];
  int nread;
  size_t nfound=0;
  while((nread=read(0, buf, BUFSIZ))>0){
    char const* p;
    for(p=buf; p=memchr(p,'\n',nread-(p-buf)); nfound++,p++) {;}
  }
  if(nread<0) { perror("Error"); return 1; }
  printf("%lu\n", nfound);
  return 0;
}

たとえばに保存し、たとえばでwcl.cコンパイルしてgcc wcl.c -O2 -o wcl、で実行します

<yourFile ./wcl

これにより、システムの1GBファイルに約370ms（繰り返し実行）で改行が散在していることがわかります。（バッファーサイズを大きくすると、時間はわずかに長くなります。これは予想されることです-BUFSIZは最適に近いはずです）。これは、私が取得している約380msに非常に匹敵しwc -lます。

Mmapingは約280msのより良い時間を与えますが、もちろん実際のファイルに制限されるという制限があります（FIFOSなし、端末入力なしなど）：

#include <stdio.h>
#include <string.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <unistd.h>
int main(){
  struct stat sbuf;
  if(fstat(0, &sbuf)<0){ perror("Can't stat stdin"); return 1; }

  char* buf = mmap(NULL, sbuf.st_size, PROT_READ, MAP_PRIVATE, 0/*stdin*/, 0/*offset*/);
  if(buf == MAP_FAILED){ perror("Mmap error"); return 1; } 

  size_t nread = sbuf.st_size, nfound=0;
  char const* p;
  for(p=buf; p=memchr(p,'\n',nread-(p-buf)); nfound++,p++) {;}

  printf("%lu\n", nfound);
  return 0;
}

私はテストファイルを作成しました：

 $ dd if=/dev/zero of=file bs=1M count=1042 

そして、いくつかのテスト改行を追加しました：

 $ echo >> 1GB 

16進エディタ。

への呼び出し回数を減らすことで、@ pskocikによって提案されたソリューションを改善できますread。1Gbファイルからチャンクを読み取るための呼び出しはたくさんありBUFSIZます。これを行う通常の方法は、バッファサイズを増やすことです。

• 面白さのために、バッファサイズを10倍または100倍に増やしてみてください。私のDebian 7ではBUFSIZ8192です。元のプログラムでは、これは12万回の読み取り操作です。おそらく、1Mbの入力バッファーで100倍に削減できます。
• より最適な方法として、アプリケーションはファイルと同じ大きさのバッファを割り当てる場合があり、単一の読み取り操作が必要になります。これは「小さな」ファイルに対しては十分に機能します（ただし、一部のリーダーのマシンには1 GBを超えるものがあります）。
• 最後に、そのように割り当てを処理するメモリマップI / Oを試すことができます。

さまざまなアプローチをベンチマークするとき、一部のシステム（Linuxなど）は、マシンのほとんどの未使用メモリをディスクキャッシュとして使用することに注意してください。しばらく前（ほぼ20年前、悪質なFAQで言及されていました）に、テキストエディターでメモリ不足の状態を処理するために開発した（あまり良くない）ページングアルゴリズムの予想外に良い結果に戸惑いました。プログラムはファイルの読み取りに使用されるメモリバッファーから動作していたため高速で実行され、ファイルが再読み取りまたは書き込みされた場合のみ速度に違いがあると説明されました。

同じことが当てはまりますmmap（別のケースではまだFAQに組み込むためにto-doリストにありますが、開発者はディスクキャッシュが改善の実際の理由であるシナリオで非常に良い結果を報告しました）。ベンチマークの開発には時間がかかり、パフォーマンスが良い（または悪い）理由を分析することに注意が必要です。

参考文献：

• 大きなバッファーを使用することは役に立ちますか？
• mmap（）と読み取りブロック
• mmap、munmap-ファイルまたはデバイスをメモリにマップまたはマップ解除（サンプルプログラムを表示）
• 13.7メモリマップI / O（GNU Cライブラリ）
• LinuxでディスクI / Oキャッシュを削除する方法
• Linuxシステムでバッファとキャッシュを空にするにはどうすればよいですか？