グラフィカルなファイル検索ユーティリティと比較して、GNUが非常に高速に検索されるのはなぜですか？

ホームディレクトリとすべてのサブディレクトリに存在しないファイルを見つけようとしています。

find ~/ -name "bogus"数秒後にその情報が提供されますが、KDEのdolphinファイルマネージャーは同じことを行うのに約3分かかりました。これは、以前のGNOMEでのbeagle経験に対応しています。

findグラフィカルな検索（コマンドラインパラメーターよりも直感的に使用できます）が遅れている間、どのようにして同じように非常に高速に処理できますか？

BalooでDolphinを具体的に見ると、単純なファイル名検索を実行している場合でも、検索ドメイン内のすべてのファイルのメタデータを検索するようです。私がトレースするときfile.soのプロセスを、私はへの呼び出しを参照lstat、getxattrとgetxattr再びすべてのファイルのため、さらにはのため..のエントリを。これらのシステムコールは、ファイル名とは異なる場所に保存されているファイルに関するメタデータを取得します（ファイル名はディレクトリの内容に保存されますが、メタデータはinodeに保存されます）。データがディスクキャッシュにあるため、ファイルのメタデータを複数回クエリするのは安価ですが、メタデータをクエリする場合とメタデータをクエリしない場合には大きな違いがあります。

findはるかに賢いです。不要なシステムコールを回避しようとします。getxattr拡張属性に基づいて検索しないため、呼び出しません。ディレクトリを横断するとき、それはlstat再帰的に検索するサブディレクトリである可能性があるため、一致しないファイル名を呼び出す必要があります（lstatregular / directory / symlink / ...などのファイルタイプを含むファイルメタデータを返すシステムコールです）。ただしfind、最適化があります。リンクカウントからディレクトリのサブディレクトリ数をlstat認識し、すべてのサブディレクトリを横断したことがわかると、呼び出しを停止します。特に、リーフディレクトリ（サブディレクトリのないディレクトリ）では、findメタデータではなく、名前のみをチェックします。さらに、一部のファイルシステムは、ディレクトリエントリにファイルタイプのコピーを保持しているため、find必要なlstat情報がそれだけである場合は呼び出す必要さえありません。

findメタデータの確認を必要とするオプションを使用して実行すると、さらにlstat呼び出しがlstat行われますが、情報が必要ない場合はファイルに対して呼び出しを行いません（たとえば、ファイルが前の条件によって除外されているため）名前の一致）。

find車輪を再発明する他のGUI検索ツールは、数十年にわたって最適化されてきたコマンドラインユーティリティよりも賢くないと思われます。Dolphinは、少なくとも、「どこでも」を検索する場合に検索データベースを使用するのに十分賢いです（UIで結果が古くなっている可能性があるという明確な制限はありません）。