1

ワークキューとスレッドを使用するポートスキャンアプリケーションがあります。

単純なTCP接続を使用し、パケットが返されるのを待つのに多くの時間を費やします（最大0.5秒）。したがって、スレッドは完全に実行する必要はありません（つまり、前半はパケットを送信し、コンテキストスイッチを実行し、処理を実行し、ネットワークデータが待機しているスレッドに戻ります）。

sys.setcheckintervalデフォルトの100（別のスレッドに切り替える前に最大100バイトコードを実行できるようにする）からを変更することで、パフォーマンスを向上させることができると思います。

しかし、スレッドまたは関数で実際に実行されているバイトコードの数がわからず、ブラインドで値を推測しているだけで、テストとテストへの依存は、測定可能な違いを示しています（実行されるコードの量が最小限であるため、これは困難です。単純です。ソケット接続、したがってネットワークジッターはsys.setcheckintervalを変更するよりも測定に影響を与える可能性があります。

したがって、sys.setcheckintervalを何に設定するかをよりインテリジェントに推測できるように、特定のコード実行（つまり、関数またはスレッドの実行の合計）に含まれるバイトコードの数を調べたいと思います。

4

3 に答える 3

3

高レベル (メソッド、クラス) に関しては、dis モジュールが役立ちます。

しかし、より細かい粒度が必要な場合、トレースは避けられません。トレースは行ごとに動作しますが、ここで説明するのは、バイトコード レベルでより深く掘り下げる優れたハックです。ネッド・バッチェルダーに脱帽です。

于 2008-11-17T05:50:00.567 に答える
2

この複雑なシステムについて推論しても、正しい答えが得られることはめったにありません。結果を測定し、最も速く実行される設定を使用します。あなたが言うように、テストがsetcheckintervalのさまざまな設定の違いを測定できない場合、なぜそれを変更するのをわざわざするのですか？測定可能な違いだけが興味深いです。テストの実行が短すぎて意味のあるデータを提供できない場合は、実行が完了するまで実行を長くします。

于 2008-11-18T03:05:53.283 に答える
1

「sys.setcheckinterval を変更することで、パフォーマンスを改善できると思います」

これはめったに機能しません。正しい動作はタイミングに依存できません。タイミングを制御することはできません。OS、ハードウェア、Python のパッチ レベル、または月の満ち欠けをわずかに変更すると、アプリケーションの動作が変わります。

選択モジュールは、I/O を待機するために使用するものです。アプリケーションは、選択を行い、他のスレッドの作業をキューに入れるメイン ループとして構造化できます。他のスレッドは、要求のキューにエントリが処理されるのを待っています。

于 2008-11-17T12:37:11.073 に答える