なぜコマンドは「find | grep 'filename'”は、「find 'filename'」よりもはるかに遅いですか？

私は両方のコマンドを試しましたが、コマンド find | grep 'filename' は単純なfind 'filename' コマンドよりも何倍も遅いです。

この動作の正しい説明は何でしょうか？

（findここではGNUを想定しています）

ただ使う

find filename

は、、filenameまたはfilenameディレクトリの場合は内部の名前、現在のディレクトリにその名前が存在しない場合はエラーを返すため、迅速です。これはls filename（filenameディレクトリの場合は再帰的）と同様の非常に高速な操作です。

対照的に、

find | grep filename

現在のディレクトリ以下からすべての名前のfindリストを生成できるようになり、フィルタリングされます。これは明らかにはるかに遅い操作になります。grep

私がいたものと仮定しています実際には意図していました

find . -type f -name 'filename'

これはfilename、現在のディレクトリまたはその下のどこかにある通常のファイルの名前として検索されます。

これはと同じくらい高速（または比較的高速）find | grep filenameですが、grep解決策は、の場合とfilename同様に、見つかった各名前の完全パスと照合さ-path '*filename*'れfindます。

混乱は、動作の誤解から生じますfind。

ユーティリティはいくつかのパスを取り、これらのパスの下にあるすべての名前を返します。

次に、ファイル名、パス、タイムスタンプ、ファイルサイズ、ファイルタイプなどに作用するさまざまなテストを使用して、返される名前を制限できます。

あなたが言う時

find a b c

あなたが求めるfind3回のパスで利用可能なすべての名前を一覧表示するa、bとc。これらが現在のディレクトリにある通常のファイルの名前である場合、これらが返されます。それらのいずれかがたまたまディレクトリの名前である場合、そのディレクトリ内のすべての追加の名前とともに返されます。

私がする時

find . -type f -name 'filename'

これにより、現在のディレクトリ（.）以下のすべての名前のリストが生成されます。次に、名前を通常のファイルの名前に制限します。つまり、ディレクトリなどではありません-type f。そして、一致する名前にさらに制限がfilename使用しては-name 'filename'。文字列filenameは、次のようにファイル名の展開パターンにすることができます*.txt（引用することを忘れないでください！）。

例：

以下.profileは、ホームディレクトリで呼び出されたファイルを「見つける」ようです。

$ pwd
/home/kk
$ find .profile
.profile

しかし、実際には、パスにあるすべての名前を返す.profileだけです（名前は1つだけで、それはこのファイルのものです）。

次にcd、1レベル上げて、もう一度やり直します。

$ cd ..
$ pwd
/home
$ find .profile
find: .profile: No such file or directory

findコマンドは、今と呼ばれる任意のパスを見つけることができません.profile。

ただし、現在のディレクトリを調べて、返される名前をのみに制限する.profileと、そこからも検索されます。

$ pwd
/home
$ find . -name '.profile'
./kk/.profile

非技術的な説明：群集の中でジャックを探すことは、群集の中のすべての人を探すことよりも速く、ジャック以外のすべてを考慮から除外します。

私はまだ問題を理解していませんが、いくつかの洞察を提供できます。

クサラナンダの場合と同様find | grepに、私のシステムでは呼び出しは明らかに高速であり、あまり意味がありません。最初に、ある種のバッファリングの問題を想定しました。コンソールへの書き込みにより、次のファイル名を読み取るための次のシステムコールまでの時間が遅くなります。パイプへの書き込みは非常に高速です：32バイトの書き込みでも約40 MiB /秒（やや遅いシステムでは、1 MiBのブロックサイズで300 MiB /秒）。したがってfind、パイプ（またはファイル）に書き込むときにファイルシステムからより速く読み取ることができるため、ファイルパスの読み取りとコンソールへの書き込みの2つの操作を並行して実行できる（find単一のスレッドプロセスだけでは実行できない）と想定しました。

それはのfindせい

2つの呼び出しの比較

:> time find "$HOME"/ -name '*.txt' >/dev/null

real    0m0.965s
user    0m0.532s
sys     0m0.423s

そして

:> time find "$HOME"/ >/dev/null

real    0m0.653s
user    0m0.242s
sys     0m0.405s

find信じられないほど愚かなことをしていることを示しています（それが何であれ）。それは実行するのにかなり無能であることがわかりました-name '*.txt'。

入力/出力比に依存する可能性があります

find -name書くことがほとんどないのなら、それが勝つと思うかもしれません。しかし、それだけではもっと恥ずかしいことになりfindます。200Kのファイル（13Mのパイプデータ）に対して何も書き込むものがなくても、次の場合は失われますgrep。

time find /usr -name lwevhewoivhol

find速さとすることができgrep、しかし、

これは、ことが判明したfindとの愚かさは、name他のテストには拡張されません。代わりに正規表現を使用してください。問題はなくなりました。

:> time find "$HOME"/ -regex '\.txt$' >/dev/null     

real    0m0.679s
user    0m0.264s
sys     0m0.410s

これはバグと考えることができます。バグレポートを提出してくれる人はいますか？私のバージョンはfind（GNU findutils）4.6.0です

通知：私はあなたが意味していると仮定しますfind . -name filename（そうでない場合は、別のものを探しています。find filename実際にはfilenameと呼ばれるパスを調べます。ファイルにはほとんどファイルが含まれていない可能性があるため、すぐに終了します）。

5000個のファイルを保持するディレクトリがあるとします。ほとんどのファイルシステムでは、これらのファイルは実際にはツリー構造に格納されているため、特定のファイルをすばやく見つけることができます。

あなたが尋ねるときにfind、名前だけチェックが必要ですファイルを見つけるために、findだろう頼むためにそのマスストレージから非常にいくつかのページを読み込みます基礎となるファイルシステムに、ファイル、およびそのファイルだけ。したがって、ファイルシステムがその価値がある場合、この操作は、ツリー全体を走査してすべてのエントリを取得するよりもはるかに速く実行されます。

あなたがプレーンを要求するときfind、それがまさにあなたがしていることです、あなたは読んでツリー全体を行き来します。すべて。シングル。エントリ。大きなディレクトリの場合、これは問題になる可能性があります（ディスクに大量のファイルを保存する必要があるいくつかのソフトウェアが2つまたは3つのコンポーネントの「ディレクトリツリー」を作成する理由です。ファイル）。

/ john / paul / george / ringo / beatlesファイルが存在し、検索しているファイルが「ストーン」と呼ばれていると仮定しましょう

find / stones

findは「ビートルズ」と「ストーンズ」を比較し、「s」と「b」が一致しない場合はドロップします。

find / | grep stones

この場合、findは '/ john / paul / george / ringo / beatles'をgrepに渡し、grepはパスが一致するかどうかを判断する前にパス全体をたどる必要があります。

したがって、grepははるかに多くの作業を行っているため、時間がかかります