openzim / openzim/python-scraperlib
Is beartype cost acceptable?
まだ誰も着手していません。
- 主要言語
- Python
- スター
- 31
- フォーク
- 27
- 平均マージ
- 3日 7時間
- マージ済み PR(30日)
- 2
説明
Context
While investigating a memory leak (fixed in #324 — a closure in RxRewriter.rewrite() was being re-decorated by beartype's claw hook on every call, permanently pinning it via beartype's own is_object_blacklisted cache), the fix removed the leak but also raised the question of how much runtime cost beartype_this_package() (used project-wide in zimscraperlib/__init__.py) actually adds. This issue is to share those numbers and discuss whether the tradeoff is the one we want.
Methodology
Ran warc2zim to completion, twice, on the same input, same machine, back to back:
warc2zim --publisher=openZIM --content-header-bytes-length=2048 \
--zim-file=www.physicsclassroom.com_56e21a6e.zim --name=www.physicsclassroom.com_56e21a6e \
--scraper-suffix "zimit 3.1.2" --output output \
--url https://www.physicsclassroom.com/ \
<local WARC, 731MB compressed, ~14.5K ZIM entries> --overwrite
wrapped in /usr/bin/time -v for wall-clock, CPU, and peak RSS.
- Run A:
zimscraperlibas-is (beartype_this_package()active). - Run B: same install, with the single line
beartype_this_package()inzimscraperlib/__init__.pycommented out (everything else identical), bytecode cache cleared between runs.
Both runs post-date the #324 leak fix, so memory is no longer confounded by that bug.
Results
| With beartype (Run A) | Without beartype (Run B) | Delta | |
|---|---|---|---|
| Wall clock time | 53:50 (3230s) | 44:08 (2648s) | −18.0% |
| User CPU time | 3835s | 3251s | −15.2% |
| Max RSS | 924,060 KB | 885,356 KB | −4.2% (noise-level) |
Both runs completed successfully with an identical entry count. Memory is essentially the same between the two (the small gap is within run-to-run noise).
Takeaway
Runtime type-checking via beartype_this_package() costs roughly 15-18% additional wall-clock/CPU time on this workload, with no meaningful memory cost of its own now that #324 is fixed.
Discussion
Is this tradeoff (broad runtime type-safety across zimscraperlib, for ~15-18% slower conversions) the one we want, or should beartype's coverage be scoped down — e.g. excluding hot paths like zimscraperlib.rewriting from beartype_this_package(), or using a cheaper BeartypeStrategy for those modules — while keeping full checking elsewhere, or allowing to fully disable beartype "on-demand" (e.g. enable it only for unit and e2e tests of scraperlib and scrapers)?
コントリビューションガイド
このリポジトリのコントリビューションガイドは索引されていません
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
zimscraperlib/init.py と beartype_this_package() の呼び出しから始め、zimscraperlib.rewriting のホットパスと、ドキュメント化されている warc2zim ベンチマークコマンドを確認します。必要に応じて対応する実行を再現し、実時間、CPU 時間、ピーク RSS を比較します。coverage をスコープ限定するか、より低コストな戦略で設定するか、選択した実行では無効化するかについて合意し、文書化できれば完了です。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- python
- 領域
- performance
- issue の種類
- リファクタリング
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 活発さ
- 静か
- 明瞭さ
- 説明が足りない
- 初心者へのやさしさ
- 35/100