Low-overhead statistical sampling mode
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 25/100
- issue の種類
- 機能追加
- 明瞭さ
- おおむね明確
- 活発さ
- 停滞
- 領域
- devtools, performance
調査の方向性
この issue では、ファイル、テスト、エントリーポイントが指定されていません。まず既存の type collector と profiling hook の経路を特定し、次にベースラインの収集と設定可能なサンプリング間隔を比較してベンチマークします。サンプリングレートを制御でき、本番環境のオーバーヘッドを記載された目標に近い値で測定でき、収集された型が引き続き有用であれば完了です。プロセス間の集約は対象外です。
索引モデルが issue の本文から書いたものです。
説明
Currently collecting types has a significant performance impact, and even rewriting type collection in C/Cython would only reduce it so much. It would be nice if the performance impact would be controllable in a way that the lower end would be, say, 1-2%. This would make it practical to collect types on production servers.
The motivation is that types collected during tests or manually running a program are unlikely to be complete, and during tests it's possible to have mocks and fakes that generate noise. By running in production on a large number of servers, it may be possible to easily collect a fairly complete picture of concrete runtime types, at least for more commonly used functions.
A potential approach is to run the type collector for roughly every N call events. At least the sampling logic would have to be implemented in C (or maybe Cython?) for acceptable performance. If N is large enough, the overhead would be dominated by the cost of invoking the profiling hook + a few machine instructions to decrement a counter and check the value.
It should be easy to validate the performance impact of the approach. The cost of collecting types isn't very important since we can make N large. However, at some point the collected types will be too sparse to be useful.
This issue doesn't cover how we'd aggregate types collected in multiple processes.
(The proposed approach is not my invention.)
- 主要言語
- Python
- スター
- 1.4k
- フォーク
- 59
- PR マージ指標
- 30日以内にマージされた PR はありません
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
dropbox/pyannotate のほかの issue
-
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
dropbox/pyannotate#124 · リアクション 3 件 ·
-
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
dropbox/pyannotate#123 ·
-
難易度 5/5 1週間以上 初心者へのやさしさ 25/100
dropbox/pyannotate#115 ·
-
難易度 3/5 1〜2日 初心者へのやさしさ 35/100
dropbox/pyannotate#109 ·
-
難易度 5/5 1週間以上 初心者へのやさしさ 25/100
dropbox/pyannotate#103 · コメント 6 件 · リアクション 1 件 ·
dropbox/pyannotate の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
BasedHardware/omi#20271 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 92/100
openai/openai-cookbook#3153 ·
メンテナーはふだん 1 日以内に返信
-
cvss-severity:high devguard l3montree-cybersecurity/devguard/devguard pkg:golang/github.com/l3montree-dev/devguard risk:low state:open
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
l3montree-dev/devguard#3146 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
-
bug confirmed issue
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
open-webui/open-webui#31849 · コメント 2 件 ·
メンテナーはふだん 1 日以内に返信