エントリがファイルにリストされている回数を見つけるとき、moreまたはfind moreに多くのリソースが必要ですか?

エントリがファイルにリストされている回数を見つけるとき、moreまたはfind moreに多くのリソースが必要ですか?

私は最近読んだfindコマンドを使用してテキストとファイルの合計発生回数を見つける方法、ファイル内の「abc」というテキストが表示される回数を見つける方法を尋ねます。そこへの答えは、find . -name "*.txt" | xargs grep -i "abc" | wc -l数を見つけるためのコマンドを提供します。

more "file_name*" |grep "abc" |wc -l以前は、特定のファイルに「abc」というテキストが表示される回数を一覧表示するために、同様のアプローチを使用していました。

これを試みたところ、moreコマンドがより速く返されることがわかりましたが、コマンドよりも約30%多くのCPUを使用しているようです(これもモニタリングしましたtopfind

15個のファイルを照会する場合、これら2つのコマンドのうち、どのコマンドがリソースを消費するかについて、より信頼できるデータを持っている人がいるかどうか疑問に思います。 30個以上のファイルはどうですか?

答え1

grepする必要があるファイルのリストがある場合は必要ありませんmore(または)。ファイルを引数として提供するだけです(2番目のツールを介してデータを転送する必要はありません)。catgrep

grep -i abc *.txt | wc -l

主な違いは、find現在のディレクトリのファイルを一覧表示するだけでなく(シェル拡張で*.txt)サブディレクトリにも繰り返されることです。

find . -name "*.txt" | xargs grep -i abc | wc -l

*.txt2番目の場合、サブディレクトリにいくつかのファイルがある場合、このファイルもコマンドgrepの引数として提供されます。

ところで、発生回数を計算するオプションがgrepあります(どちらも必要ありません)-cwc

grep -c -i abc *txt

また、合計回数ではなく、各ファイルの発生回数のみを提供します。

答え2

「ハードデータ」はありませんが、考えてみてください。

more一度に 1 画面ずつテキストのページを付けるために使用される (raw) フィルタです。これは、「CRTビュー用」インタラクティブな使用のためのものです。したがって、出力をに送信しても、提供されたフィルタリング機能を介して各ファイルを表示するためにpipeメモリとCPUリソースを使用します。more

catあなたの例では、代わりに使用する方が正確ですmore。さらに一歩進んで、フィルタプログラムの追加のステップを削除してgrepファイルを直接検索することによって(出力をパイプにリンクするのではなく)、サンプルコマンドをより効率的にすることができます。

findコマンドは遅いので、現在の作業ディレクトリの "file_name *"でfind始まり、ディレクトリ構造を巡回して.動作します。more

答え3

一見すると、報酬を受けようとする無駄な試みのように見えますが、grepを呼び出す前にすべてのファイルを分類すると、次のようになります。

cat *.txt | grep -ci abc  

grep この合計を計算します。あなたはサブディレクトリを繰り返すのが好きなので(そうではありませんか?)、サブディレクトリでもこれを行うことができます。

find -name "*.txt" -exec cat {} + | grep -ci abc

関連情報