walk
ディレクトリツリーの下にいくつのエントリがあるかを事前に知る方法がないため、それ自体では進行状況を確認できません。*
ただし、 を使用するほとんどのプログラムではwalk
、実際にはファイルに対して何かを行っているため、通常、暗黙的なstat
呼び出しよりもはるかに長い時間がかかります。たとえば、最初のプログラムを取得os.walk
するにlist(os.walk(path))
は 2.301 秒かかりますが、実際の機能 (これらのファイルのごく一部を操作するだけであるにもかかわらず) は 139.104 秒かかります。そして、この種のことはかなり典型的だと思います。
そのため、最初にウォーク全体を (たとえば、 を使用してlist(os.walk(path))
) 読み取り、次にその情報を使用して実際の作業の進行状況を生成できます。
list(os.walk(path))
現実的なプログラムでは、実行中に「サイズを決定しています...」のようなラベルが付いた「不確定な進行状況バー」を表示し、それを「0/12345 ファイル」のパーセンテージ進行状況バーに置き換えたいと思うでしょう。これで完了です。(実際、アイデアを考えたので、まさにその不確定な進行状況バーをプログラムに追加するつもりです…)
(シングルスレッドの対話型プログラムの場合、単に をブロックしたくないことは明らかですlist(os.walk(path))
。メイン スレッドへのコールバックを使用してバックグラウンド スレッドでブロックするか、walk
オブジェクトを1 回繰り返しrunLater
、残りを毎回イベントループなど)
* これは、ファイルシステムや OSがそのようなことを行うことができなかったからではありません。明らかにいくつかのトレードオフがあります。たとえば、ツリー全体の更新カウントをたどる必要がある場合、多数の小さなファイルの作成と削除は非常に遅くなります。従来の Mac は、キャッシュされたカウントを Finder Info に保持することでこの問題を解決していました…これは素晴らしいことでしたが、それは、戻るのに 1 秒または 1 分かかる可能性のある呼び出しを意味し、どちらを事前に予測する (または中断する) 方法がないことを除いては優れていました。プログラム的に。