Repository navigation
perf: optimize repetition detection for high-frequency streaming #55
Description
背景
GLM-5.1 thinking corruption fix（Issue #52）でrepetition detectionを実装。
問題
現在のdetectRepetition()はO(n*m)で���全てのtext-deltaイベントで呼ばれる。
高速ストリーミング時に性能影響の可能性がある。
対策案
- N文字蓄積ごとにチェック（例：500文字ごと）
- Rolling hashアルゴリズムの採用
- キャッシュベースの最適化
現状
実測では1ms以下で完了するため、現時点ではブロッカーではない。
高速モデル（GPT-5.x等）での負荷テスト後に再評価。
関連
- Issue [Bug] GLM-5.1 thinking output corruption — repetition loop + tool call leak #52 (GLM-5.1 thinking corruption)
- Upstream Issue: [BUG] GLM-5 model pollutes context window with broken thinking output anomalyco/opencode#16903
Activity
terisuke commentedon Apr 5, 2026
進捗更新: detectRepetition は repetition.ts に抽出済み (PR #70)。ただしアルゴリズム自体は同一のネステッドスキャンのまま (repetition.ts:8)、processor.ts:162,373 で毎 delta 呼び出し。性能最適化は未着手。
terisuke commentedon Apr 6, 2026
Note: upstream/dev has the repetition detection removal in preparation on feature branches (not yet merged to dev). When upstream merges, repetition.ts will be deleted. No optimization needed.
terisuke commentedon Apr 8, 2026
Closing as won't-fix for now. Per the issue body itself:
The repetition detection runs in sub-millisecond time. No measurable performance impact observed with current models (GPT-5.4, GLM-5.1, Claude Sonnet 4.5). If future high-speed models expose latency, reopen with profiling data.