# AFK widget benchmark

## Scope and rationale

Only widget redraw scheduling changed; agent work, queue order, prompts, and completion semantics did not.
The previous 700-ms interval requested redraws even when the art was identical or the cat was asleep.
The candidate schedules the same visible blink transitions: 2,100 ms awake, then 700 ms blinking.
Invalidation cancels animation while napping and resumes it for new work without resetting an existing awake deadline.

## Method

Use `//extensions/afk:bench` through Mise.
The task uses Node's mock clock to execute 1,024 700-ms ticks per workload, approximately 12 minutes of widget time.
Its TUI host renders the actual widget at width 80 with ANSI color on each redraw request; this is not a full Pi-terminal or live-model benchmark.
Awake and asleep workloads run separately.
Three warmup workloads per implementation are discarded before 31 paired measurements, alternating baseline/candidate execution order.
Paired measurements control some within-process thermal and scheduling drift.
Pairs outside either implementation's 1.5-IQR bounds are removed, with counts reported.
The report includes unfiltered savings as a sensitivity check, retained mean/SD, CPU time, exact redraw counts, and paired-bootstrap 95% confidence intervals from 10,000 seeded resamples.
Confidence intervals describe within-process workloads, not deployment-wide performance.

Optional arguments: `--baseline <module.ts>`, `--profile <output.cpuprofile>`, `--output <report.json>`.
A baseline module must export `createAfkWidget` and resolve its runtime imports independently of the snapshot directory.
Without `--baseline`, both sides use current code, serving as a noise control.
`--profile` records the baseline with Node's V8 CPU profiler before the unprofiled timing comparisons.

## Recorded evidence

Environment: Node 24.18.0, Pi TUI 1.0.2, Android arm64.
No dependency or system changes; CPU frequency and Android background activity were not controlled.
The baseline snapshot preserved the original interval/frame implementation; only runtime import paths were relocated.
The initial 4,096-tick control had identical redraw counts for both implementations, with wall-time confidence intervals spanning zero savings.
Its CPU profile attributed 79.48% of 7,233 samples to `truncateToWidth`, plus 5.02% to garbage collection.
Rendering unchanged frames dominated the measured workload.
Final comparisons reduced the workload to 1,024 ticks on both sides for faster repeated measurements.

Three independent process runs, each with 31 paired samples:

- Awake redraws: 1,024 → 512; redundant redraws: 512 → 0.
- Asleep redraws: 1,024 → 0; sleeping widget has no animation timer.
- Awake retained mean savings: 44.8%, 32.8%, 38.0%.
- Awake per-run 95% savings intervals: [36.0%, 52.9%], [22.7%, 42.2%], [35.1%, 40.8%].
- Awake baseline SD: 34.5, 24.2, 11.3 ms; candidate SD: 21.5, 29.2, 3.0 ms.
- Awake removed pairs: 4, 3, 11; asleep removed pairs: 0, 4, 0.
- Asleep simulated workload savings exceeded 99.97%; its remaining cost is the benchmark's empty mock-clock loop.

A fourth sensitivity run retained 43.0% awake savings, with 40.3% before outlier removal and a [31.5%, 53.1%] retained 95% interval.
That run removed 3 awake pairs and 8 asleep pairs; substantial noise limits precision, but exact redraw counts and unfiltered savings support the mechanism independently.

## Verification and limits

Behavior tests passed on the original implementation before optimization: blink cadence, invalidation, waking, width/theme handling, disposal, real Pi queue and completion contracts.
Additional candidate tests enforce zero sleeping timers/redraws and only visible awake transitions.
These results establish reduced widget work, not faster model inference, measured battery savings, or end-to-end Pi CPU percentages.
Temporary snapshots, profiles, and JSON reports were removed after recording this evidence.