perf(#255): emit now-playing artwork only on track changes#289
Conversation
The media-remote-helper fired a repeating timer that base64-encoded the
now-playing artwork (hundreds of KB–several MB) and streamed it over IPC
on every tick, pegging the daemon at ~28% CPU even when the track never
changed.
Tag each helper payload with an `event` ("track-change" | "tick") and
attach `artwork_base64` only on track-change. The daemon backfills the
cached cover on ticks and clears it when a track-change carries no
artwork (genuinely cover-less track). Composes with the #270 decode
memoization: #270 avoids re-decoding an unchanged base64, #255 avoids
re-transmitting it.
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
Warning Review limit reached
More reviews will be available in 52 minutes and 20 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (5)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
Closes #255
背景
media-remote-helper.swiftの周期 Timer が、楽曲が変わっていなくてもアルバムアート（数百 KB〜数 MB）を毎回 base64 化して IPC で daemon に流していた。再生中は daemon CPU が約 28% に張り付く原因。変更
helper の各ペイロードに
eventタグ（"track-change"/"tick"）を付与し、artwork_base64は track-change のみ に添付する。.trackChange、3 秒周期の elapsed 更新は.tick。tick ではアートワークフィールドを省略。MediaRemoteDataSourceImpl）— tick でアートワーク不在のときは直前の cover を補完。track-change でアートワーク不在のときは「カバーを持たない楽曲」を意味するのでキャッシュをクリアし、stale な前曲カバーを表示しない。#270 との合成
本 PR は #270（base64 デコードのメモ化）と相補的に効く。#270 は「変わらない base64 を再デコードしない」、本 PR は「そもそも変わらない base64 を再送信しない」。
テスト
MediaRemoteDataSourceImplTestsに 3 ケース追加（対象スイート 13 件・フルスイート 945 件 green）:tick payload without artwork reuses the last track-change cover— track-change で cover → tick で cover 再利用、デコード 1 回track-change payload without artwork clears the cached cover— cover → cover 無し track-change → tick で[cover, nil, nil]、デコード 1 回tick before any track-change yields no artwork— tick 先行 → nil、デコード 0 回検証状況
swift buildgreen /MediaRemoteDataSourceImplTests13 件 green / フルスイート 945 件 greenhas_info:false）かつ VM ゲストにも再生中楽曲がないため未計測。lyra benchmarkの合成シナリオ（idle / cpu_spike / memory_alloc）はこのアートワーク IPC 経路を踏まないため代替にならない。「track-change のみ送出 / tick は再利用」の不変条件はユニットテストで担保済み。期待効果は IPC 帯域 1/30〜1/100 + base64 CPU を楽曲変更時のみに限定。