Reduce Juice idle power usage - #18
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 58287f489f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| } catch { | ||
| state = .unavailable | ||
| return .unavailable |
There was a problem hiding this comment.
Retry stale checkState transport failures
When the connection is invalidated or interrupted while this handshake is in flight and its error handler wins, the caught error may belong to a context that is no longer current. This branch nevertheless publishes .unavailable and returns immediately, so the replacement connection is never checked and a helper crash/update race can falsely report that the helper is unavailable. Mirror the stale-success path by checking isCurrent(context) in the catch and continuing when it is false.
Useful? React with 👍 / 👎.
Benchmark repeat: launch-idle compute usageRepeated on the M4 Mac mini ( Method
InterpretationThis repeat independently confirms that the PR materially reduces background compute. Under true launch-idle conditions, attributable app-plus-helper compute energy was about 10.9x lower. The result is also consistent with the earlier hidden-instantiated-popover run, where total coalition compute fell from 0.03467 W to 0.00945 W (72.7% lower) and app CPU fell from 10.08% to 4.03% (60.0% lower). The watt values are kernel coalition CPU/GPU/ANE energy attributable to Juice, not whole-system wall-outlet power. They are useful for comparing these two builds under the same workload but should not be presented as total Mac power draw. |
What changed
Why
The installed app could sustain roughly 38-41% CPU because hidden app-scoped SwiftUI views were re-rendering every two seconds. Helper requests also repeated a connection-scoped handshake. In signed isolated runtime sampling, the patched app was usually at 0% CPU with brief 0.5-0.7% activity, about a 99.4% sampled reduction. A short-window coalition comparison also moved directionally from about 1.07 W to 0.0006 W; that watt figure is diagnostic rather than a calibrated benchmark.
Laptop battery behavior is intentionally preserved: laptops still perform the initial battery read, keep the 60-second polling cadence, and react to Low Power Mode notifications. Only Mac mini mode avoids battery-specific background resources that can produce no readings.
Verification