0

私は、ディレクトリをスキャンする「古い」方法と「新しい」より高速な1.7の方法の間でジレンマに陥っています。

ドライブ上のすべてのディレクトリをスキャンして、同様のツリー構造を構築する必要があります。1.6では問題はありませんが(10倍遅いことを除いて)、FileFisitorにはいくつかの大きなハードルがあります。

ディレクトリに含まれるアイテム(ファイル+サブディレクトリ)の数を事前に知るにはどうすればよいですか?

  • 古い方法:File[] files = path.listFiles();そしてそれfiles.lengthが答えです。
  • 新しい方法:コールバック関数public FileVisitResult preVisitDirectory(Path path, BasicFileAttributes bfa){}で、カウントはどこにありますか?

サブディレクトリごとにスケーラブル配列(ArrayList)を使用すると、パフォーマンスとすでに大きなメモリフットプリントの両方が確実に損なわれるため、通常の固定長配列を使用する必要があります。私が考えていた別の方法は、再利用可能なマスターアレイを使用し、長さがわかったら、それを宛先アレイにコピーすることです。ただし、これは再帰的な性質、およびディレクトリとファイルがグループ化されるのではなくインターリーブされてウォークされるという事実と矛盾します。最初にディレクトリをウォークし、次にファイル(私の調査では実行できないと言っています)をウォークさせることができない限り、再帰の深さごとに(潜在的に無限の)マスター配列が必要になります。

4

1 に答える 1

7

私は本当にこの仮定に疑問を投げかけます:

サブディレクトリごとにスケーラブル配列(ArrayList)を使用すると、パフォーマンスとすでに大きなメモリフットプリントの両方が確実に損なわれます。

これにはどのような根拠がありますか?ファイルシステムへのアクセス速度によって、パフォーマンスが制限される(または少なくとも影響を受ける)可能性があることに注意してください。

私は(この性質のほとんどの質問に関して)、事前に仮定を立てるのではなく、単純で拡張可能な解決策を試し、実際に問題を特定すると思います。

于 2012-11-19T10:43:08.083 に答える