一致するものを見つけると、grep後続の検索に最初の検索よりもはるかに少ない時間がかかることがよくあります。たとえば、25秒対2秒です。明らかに、これは最後の実行のデータ構造を再利用することによって行われません。そのデータ構造は解放されなければなりません。timeでコマンドを実行し、grep興味深い現象を発見しました。
real 24m36.561s
user 1m20.080s
sys 0m7.230s
残りの時間はどこに行きましたか？毎回より速く実行する方法はありますか？ （たとえば、grepファイルを検索する前に別のプロセスからファイルを読み取るようにしてください。）
答え1
それはしばしば関連していますページキャッシュ。
最初は、データをディスクから（物理的に）読み取る必要があります。
2番目に（サイズが小さいファイルの場合）、ページキャッシュに存在することがあります。
したがって、まず、次のようなコマンドを発行できます。猫(1)（大きすぎない）ファイルをページキャッシュ（RAMなど）に入れてから、2番目正規表現(1)（またはファイルを読み取るすべてのプログラム）は通常、より速く実行されます。
（たまにディスクからデータを読み取る必要があるかもしれません）
参照（時々アプリケーションには便利ですがまれに）先読み(2)&posix_fadvise(2)おそらくクレイジーウェス(2)&同期(2)&同期(2)など....
また読んでくださいLinuxAteMyRAM。
ところで、プログラムのベンチマーク時に複数回実行することをお勧めする理由もここにあります。また、これがより多くのRAMを購入するのが役に立つ可能性がある理由です（データを保存するためにすべてのRAMを使用しないプログラムを実行する場合も同様です）。
もっと知りたい場合は、次の本を読んでください。オペレーティングシステム：3つの簡単な部分
答え2
ネットワークストレージ環境では、サーバーとは別のファイルマネージャにあるファイルに初めてアクセスするときに比較的大きな遅延が発生する可能性があります。ファイルがサーバーからアクセスされると、ローカルにキャッシュされ、その後のデータアクセスがはるかに高速になります。
これは、grepではなくファイルデータのチェックサムのみを計算する実験です。最初の呼び出しは遅く、その後の呼び出しは高速です。
> du -Dh file_348m
348M file_348m
> /usr/bin/time md5sum file_348m
738709b181b52ddfcef3413997f91462 file_348m
0.60user 0.15system 0:03.02elapsed 25%CPU (0avgtext+0avgdata 1524maxresident)k
708144inputs+0outputs (0major+80minor)pagefaults 0swaps
> /usr/bin/time md5sum file_348m
738709b181b52ddfcef3413997f91462 file_348m
0.67user 0.06system 0:00.73elapsed 99%CPU (0avgtext+0avgdata 1524maxresident)k
0inputs+0outputs (0major+80minor)pagefaults 0swaps
> /usr/bin/time md5sum file_348m
738709b181b52ddfcef3413997f91462 file_348m
0.65user 0.07system 0:00.73elapsed 99%CPU (0avgtext+0avgdata 1524maxresident)k
0inputs+0outputs (0major+80minor)pagefaults 0swaps
> /usr/bin/time md5sum file_348m
738709b181b52ddfcef3413997f91462 file_348m
0.66user 0.06system 0:00.73elapsed 99%CPU (0avgtext+0avgdata 1524maxresident)k
0inputs+0outputs (0major+80minor)pagefaults 0swaps