0

これが正しいか間違っているかはわかりませんが、常識に基づいて、orよりcommand fileもわずかに高速です。command dir/filecommand dir1/.../dirN/file

ここで、それが正しいと仮定して、さまざまな量のディレクトリ内の多数のファイルを操作するスクリプトとコマンドについて考えてみましょう (たとえば、gentoo カーネルのコンパイル)。スクリプトまたはプログラムがcd、多くのファイルを保持しているディレクトリに入るほどスマートである場合、パフォーマンスは向上しますか?

これらのポインターを何百回も何千回もたどらないことで節約された時間は、ディレクトリに出入りするのにかかる時間を補うことができるように思えます。

今、私は私の質問をします：

  • パフォーマンスが向上する可能性はありますか?
  • もしそうなら、どのようにベンチマークできますか？
  • ベンチマークが可能な場合、ディレクトリ内外で費やされた時間を均等にするには、ディレクトリ内にいくつのファイルが必要cdですか?
  • これは、Java、PHP、Python などのファイル操作にも影響しますか?
4

2 に答える 2

1

chdir を実行すると、ディレクトリを検索して dentry を作成します。後で dir/file を呼び出すと、すでに dir の dentry が含まれているはずです。同様に、dir/file1 および dir/file2.... dir/fileN にアクセスする場合、dir の検索は 1 回だけ行う必要があります。したがって、パフォーマンスの向上があるとは思えません。「Make」は、他の理由で chdir を実行する場合があります。

于 2013-03-10T07:10:26.927 に答える
1

パフォーマンスが向上する可能性はありますか?

count: 10,000,000 (50,000 ファイル、200 回ループ)

stat *: リアル - 8m 47.112s
cd ...: リアル - 8m 47.475s
stat dir/dir/dir/*: リアル - 9m 33.609s

もしそうなら、どのようにベンチマークできますか？

テストには次のコマンドを使用しました。

mkdir dir;
mkdir dir/dir;
mkdir dir/dir/dir;
cd dir/dir/dir;
touch $(seq 1 50000);
time for i in $(seq 1 200); do stat * > /dev/null; done;
cd ../../../;
time for i in $(seq 1 200); do stat dir/dir/dir/* > /dev/null; done;
time $(cd dir/dir/dir; for i in $(seq 1 200); do stat * > /dev/null; done; cd ../../../);

ベンチマークが可能な場合、cd を出し入れするのに費やした時間でさえ、ディレクトリに何個のファイルが必要ですか?

他のプロセスが実行されていない専用システムなしで正確な数を知ることは不可能ですが、「損益分岐点」の数は次のように見えます。

1方向: 2,500
2方向: 1,250
3方向: 1,000

これは、Java、PHP、Python などのファイル操作にも影響しますか?

常識を使用すると、パスによってこのわずかな時間差が追加されると思いますが、私が考えることができる唯一の実際の解決策は、すべてのインクルード ファイルを 1 つのディレクトリに配置し、別のインクルード ファイルを作成してすべてのインクルードを含めることです。ランタイムコードに「大量インクルーダー」を含めます。

于 2013-03-10T22:04:23.497 に答える