0

新しいサブディレクトリのディレクトリを監視し、ループ内の各サブディレクトリに作用する python スクリプトを作成しました。これらのサブディレクトリを作成する外部プロセスがあります。各サブディレクトリ内には、テキスト ファイルと多数の画像があります。テキスト ファイルには、画像ごとに 1 つのレコード (行) があります。サブディレクトリごとに、スクリプトはテキスト ファイルをスキャンし、いくつかの外部プログラムを呼び出します。1 つは空白の画像 (カスタム exe) を検出し、次に「mogrify」(ImageMagick の一部) を呼び出して画像のサイズを変更して変換し、最後に 7 を呼び出します。 -zip は、変換されたすべての画像とテキスト ファイルを 1 つのアーカイブにパッケージ化します。

スクリプトは正常に実行されますが、現在はシーケンシャルです。各サブディレクトリを一度に 1 つずつループします。これはデュアル CPU マシン (合計 8​​ コア) で実行されているため、マルチプロセッシングを実行する良い機会になると思います。

特定のサブディレクトリの処理は、他のすべてのサブディレクトリから独立しています...それらは自己完結型です。

現在、os.listdir() への呼び出しを使用してサブディレクトリのリストを作成し、そのリストをループしています。サブディレクトリごとのコード (変換など) をすべて別の関数に移動してから、各サブディレクトリを処理する別のプロセスを何らかの方法で作成できると思います。私は Python に少し慣れていないので、そのようなマルチプロセッシングにアプローチする方法についていくつかの提案をいただければ幸いです。Python 2.6 を実行している Vista x64 を使用しています。

4

1 に答える 1

0

この設計が同時実行性の恩恵を受けるように聞こえることに同意します。multiprocessing モジュールを見てください。threading モジュールを見て、速度を比較することもできます。マルチプロセッシングとスレッディングの利点を得るために必要なコアの数を正確に判断するのは難しく、8 コアはスレッディングの方が高速な範囲内に十分収まります (GIL にもかかわらず)。

設計の観点から、私の最大の推奨事項は、可能であればプロセス間の相互作用を完全に回避することです。プロセスの作成をトリガーするイベントを 1 つの中央スレッドで検索し (サブディレクトリの作成だと思いますか?)、サブディレクトリを処理するプロセスを生成します。それ以降、生成されたプロセスは他のプロセスと対話することはありません。あなたの説明から、これは可能であるように思われます。

最後に、 Python 3.0への移行に対する励ましの言葉を追加したいと思います。2.x にとどまるという話はたくさんありますが、3.0 はいくつかの実際の改善を行っており、ますます多くの人々が Python 3.0 に移行し始めるにつれて、2.x のツールとサポートを入手することはより困難になるでしょう。

于 2009-08-26T06:09:45.727 に答える