Files
ai-app/docs/bench/iris-phone-2026-09-06-before-fixes.md
T

1.8 KiB

iris bench report from Iris's phone, 2026-09-06, before the phone fixes

Build 46246ea (Vulkan, bench v1: 24-swipe scroll loop then 400 streamed events), run by Iris on her Pixel 9 Pro XL before the first-touch wipe, the missing bold faces, the density scale and the status-bar inset were fixed -- so the rows were drawn at roughly a third of their intended size and the run may have included frames after the wipe. Preliminary, kept because it is the first iris number from real hardware. Compare with compose-phone-2026-09-06.md, taken on the same phone with the same fixture and gesture loop.

Reading it: the phone is 120 Hz (8.3 ms budget). janky% here counts frames over 16.7 ms, so it is not Compose's late (over 8.3 ms). Like for like: iris p50 6.2 ms vs Compose 7.7 ms; p90 32.0 vs 29.2; p99 42.1 vs 41.1. cpu_p50=4.7ms is iris's own per-frame CPU work on the phone, against 0.2-0.4 ms on the emulator's x86 cores. Process CPU 15.6 s vs 20.9 s, but over a shorter run (692 frames vs 1613 -- iris only renders on change and had no fling settle time), so per-second CPU is not directly comparable; peak RSS 365 MB vs 587 MB. Battery current mean 563 mA vs 419 mA is the one figure that reads worse, and it is the least comparable: 22 samples vs 39, over runs of different length and different idle share. Bench v2's per-phase accounting is what makes these comparable.

iris bench report
frames=692 janky%=32.37 p50=6.2ms p90=32.0ms p99=42.1ms worst=52.6ms (measures redraw-start to after present() is called, not GPU/compositor completion) cpu_p50=4.7ms gpu_wait_p50=1.3ms (redraw-start-to-submit vs. submit-to-after-present)
  scroll: 6 cycles (24 swipes), streamed 400/400 fixture events
  process CPU time over this run: 15554ms
  peak RSS: 365328kB
  battery current: mean -563493µA over 22 samples (min -1807812, max -132812)