性能改善: Range Helper のメモリ効率改善

[apokamo]

概要

get_*_range メソッドのオンメモリ結合アーキテクチャを見直し、
大規模データ取得時のメモリ使用量を削減する。

---

現状の課題

アーキテクチャ

[日付1] → DataFrame1 ─┐
[日付2] → DataFrame2 ─┼─→ list[DataFrame] ─→ pd.concat() ─→ 結果
  ...                 │
[日付N] → DataFrameN ─┘

• 結合前に全DataFrameがメモリに保持される
• N日分 × 1日あたりのデータ量 がピークメモリ使用量
• 並列/直列に関係なく同じ問題（pd.concat の構造的制約）

影響シナリオ

シナリオ	日数	概算データ量	問題度
1ヶ月分の株価	~20	数十MB	低
1年分の株価	~250	数百MB	中
5年分の株価	~1,250	数GB	高

---

解決方針（案）

A案: チャンク結合

[日付1-30] → concat → chunk1 ─┐
[日付31-60] → concat → chunk2 ─┼─→ concat → 結果
  ...                          │

• 一定日数ごとに部分結合し、中間DataFrameを保持
• ピークメモリを 全体 / チャンク数 に削減

B案: イテレータAPI追加

def iter_price_range(self, start_dt, end_dt) -> Iterator[pd.DataFrame]:
    """1日分ずつyieldする（メモリ効率重視）"""
    for date in dates:
        yield self.get_prices_daily_quotes(date=date)

• 利用者が逐次処理可能
• 既存APIとの互換性維持（get_*_range は現状維持）

C案: ファイルキャッシュ

• 中間結果をtempファイルに書き出し
• 最後にまとめて読み込み・結合
• I/Oオーバーヘッドとのトレードオフ

---

Constraint

1. 既存API互換: get_*_range の戻り値型（DataFrame）は変更しない
2. デフォルト挙動: 現状維持（小規模利用者への影響回避）
3. オプトイン: 大規模取得者向けに新API or パラメータで選択可能に

---

テスト検証観点

• メモリ使用量のベンチマーク（改善前後の比較）
• 出力DataFrameの等価性（内容・順序が既存と一致）
• 大規模データでのOOM発生有無

---

優先度

Low - 現状で実用上の問題報告なし。将来的な改善検討。

---

関連

• Phase 3.7 セクション4: 日付範囲取得ロジックの共通化 (_fetch_date_range) #40: Range Helper共通化
  • Phase 3.7 セクション4: 日付範囲取得ロジックの共通化 (_fetch_date_range) #40 完了後に対応すると、_fetch_date_range 1箇所の修正で全メソッドに適用可能
  • Phase 3.7 セクション4: 日付範囲取得ロジックの共通化 (_fetch_date_range) #40 はブロッカーではない（独立して対応も可能だが非効率）

🤖 Generated with Claude Code