Unixのgrepは、長い検索語または短い検索語を使用してより速く動作しますか？

長い検索用語または短い検索用語を探す方が速いですか？それとも速度に影響しますか？つまり、検索語句をできるだけ正確にする必要がありますか？

100 000を超えるファイルがあり、各ファイルには20〜5000行を超えるデータが含まれています。通常、grepは検索用語の1つのインスタンスのみを見つけるために使用されます。

検索語句がでSEARCHTERM、次のような行になるとします。

NAD+DP+1234567890:92++UNIQUE+NAME+SEARCHTERM++12345+FI'

「SEARCH」または「SEARCHTERM」を探す方が速いですか？この場合、他の無関係な行でも一致が見つかっても気にしないとしましょう。

これは私が現在それをしている方法です：

grep NAD+DP 123* | grep SEARCHTERM

しかし、それでもかなり遅いと思います。大まかなファイル名を知っている場合でも、通常、データを見つけるのに約3〜5分かかります。これにより、範囲が約10 000ファイルに制限されます。

それでは、検索語句を長くしたり短くしたりすると役立ちますか？私の知る限り、grepは特定の長さの単語の「ブロック」を探しますか？

参考資料：

GNU grepは、よく知られているBoyer-Mooreアルゴリズムを使用します。このアルゴリズムは、最初にターゲット文字列の最後の文字を探し、ルックアップテーブルを使用して、一致しない文字が見つかった場合に、入力をどれだけ先にスキップできるかを伝えます。

なぜGNU grepの高速です。

アルゴリズムは、検索される文字列（パターン）を前処理しますが、検索される文字列（テキスト）は前処理しません。[...]一般に、パターンの長さが長くなるほど、アルゴリズムはより速く実行されます。

ボイヤー-ムーア文字列検索アルゴリズム。

結論：より長い文字列を使用します。

さて、楽しみのためのベンチマークを少し：

# Initialisation
cd $(mktemp -d) && dd if=/dev/urandom of=random bs=1M count=1000
# Version
grep --v` # grep (GNU grep) 2.9
# Benchmark
(for s in 'short' 'this is not so short and we could even consider this as pretty long'; do for t in {1..10}; do time grep "$s" random; done; done ) 2> result

結果：0.952秒は短い文字列の平均、0.244秒は長い文字列の平均です。

注意：長さは考慮される唯一の基準ではありません。

SEARCHまたはSEARCHTERMを使用して自分で試すことができます。また、2つのgrepコマンドの順序を変更してみてください。とにかく、唯一の有用なオプションは、1つの検索に複数のCPUコアを使用することです。parallelコマンドを参照してください。

より具体的な検索語句を指定しても、著しく高速になるとは思いません。

検索するファイルが非常に多いため、検索を高速化するには、何らかの方法でデータにインデックスを付ける必要があります。

私はいくつかの方法を提案できます：

• データベース（PostgreSQLまたはMySQL）を作成し、データをデータベースにインポートします-1行に1つのファイル、FTS（全文検索）インデックスを追加します。データベースをクエリするユーティリティを作成します。

• よりきめ細かい方法でデータベースにデータをインポートします。おそらく1行を1行（または複数のテーブル）にインポートし、インデックスを使用してデータを検索できるようにインデックスを作成します。データベースをクエリするユーティリティを作成します。

• ファイルをgitリポジトリに追加しgit gc、を使用git grepして圧縮し、検索に使用します。私の経験でgit grepは、標準よりもgrep10倍から100倍高速です。

論理的には、期間が短いほど、必要なCPU時間は少なくgrepなります

if (filechar[i] == pattern[i]) ...

少ない回数。実際には、a grepはI / Oバウンドであり、CPUバウンドではないので、問題にはなりません。