呼び出しのパラメータ順序がfind結果の速度にどのような影響を与えますか？
たとえば、（A）を比較します。
find -name dir -type d
そして（B）
find -type d -name dir
または他のパラメータの組み合わせ（例えば、-orまたは使用-and）。findどんな面でもスマートになりたいです。
timeAとBを5回繰り返して統計を収集してみました。しかし
11.86, 7.23, 5.25, 5.87, 7.16
AとBの場合：
9.73, 6.56, 8.69, 7.14, 6.35
これは実際に結論ではなく、両方の平均がすぐに近づき、7.5s差がかなり高くなります。
もう一度質問をしたい場合は、パラメータの順序が重要ですかfind？
ベストアンサー1
高価なのは、ファイルに対してシステムコールを実行することです（システムコール自体とI / Oの両方について）。
-type同じものにはファイルへのシステムコールが-mtime必要です。 、、しないでください（もちろん、内容を読むために含まれているディレクトリに対してシステムコールを実行しますが）。lstat(2)-name-path-regex
通常、これはとにかくfind実行されますがlstat()（情報が提供されていない限り、ファイルに入るにはファイルがディレクトリであるかどうかを知る必要があるためですreaddir()）、場合によってはディレクトリなしで動作できます。たとえば、ディレクトリに3つ未満のリンクがある場合、一部のファイルシステムではfindサブディレクトリがないことが知られており、一部のfind実装lstatではsを実行しないことで最適化します。
-xtypestat(2)、、、、、、につながる可能性-printf ...があります。-lsstat()lstat()readlink()-lnamelstat()readlink()
そのため、おそらく-name// ...-pathを-regex最初に入力したいと思います。ファイルを除外できる場合は、1つ以上のシステム呼び出しを回避できます。
今、aは-regexaよりも高価ですが、-name交換すればどのくらいを受けることができるのかよくわかりません。
また、一部のfind実装（例：GNU）では、find可能であればデフォルトでチェックの順序を変更します。望むより：
info find 'Optimisation Options'
GNUシステム（gnu.orgで利用可能最新バージョンのGNUの場合findutils）。
通常、GNUシステムでテストする場合、両方のコマンドは同じことを行います。とにかく前に進むだろうからfindです-name。
したがって、-type d -name ...vsが-name ... -type d機能するには、findこれらの述語を並べ替えて最適化しない実装と、lstat()すべてのファイルに対して実行せずにいくつかの最適化を実行する実装が必要です。
実装に関係なく（大きな）違いがあります。
find . -name 'x*' -exec test -d {} \; -print
比較：
find . -exec test -d {} \; -name 'x*' -print
find-exec順序を変更すると機能的な違いが生じる可能性があるため、順序を変更することはできません（find実行されたコマンドが単にテスト用であるのか、それとも他のタスクを実行するためのものかを知る方法はありません）。
もちろん、これは-exec ... {} \;プロセスを分岐し、プロセスでコマンドを実行し（それ自体で多くのシステムコールを実行する）、プロセスと終了コードを待つことを意味するため、他の述語よりもはるかに高価です。
$ time find /usr/lib -exec test -d {} \; -name z\* -print > /dev/null
1.03s user 12.52s system 21% cpu 1:03.43 total
$ time find /usr/lib -name z\* -exec test -d {} \; -print > /dev/null
0.09s user 0.14s system 62% cpu 0.367 total
（最初は（56685）testのすべてのファイルが必要で/usr/lib、2番目はz（147）という名前のファイルのみが必要です。）
-exec test -d {} \;と同じではありませんのでご注意ください-type d。これはGNU専用のポータブルバージョンです-xtype d。