32 lines
1.6 KiB
Markdown
32 lines
1.6 KiB
Markdown
# Mobile leave-planner benchmark
|
|
|
|
Open the deployed application at `/benchmark` on the reference phone. Tap
|
|
**Run benchmark**, wait for the five scenarios to finish, then tap **Copy
|
|
report** and save the tab-separated output with the date and build identifier.
|
|
|
|
The harness measures preparation, planning-to-outcome latency, later trace
|
|
delivery, and total wall time separately. It records the outcome, last
|
|
completed quality stage, placement count, determinism, trace status, and trace
|
|
candidate count. `PlanningIncomplete` is not a conflict: its last completed
|
|
stage and incumbent are retained.
|
|
|
|
## Protocol
|
|
|
|
- Record phone model, OS version, browser/version, application build, and
|
|
battery level.
|
|
- Use a cool phone, unplugged, with other applications closed. Record whether
|
|
the device became warm or throttled during the run.
|
|
- Run the benchmark three times after one warm-up run. Do not interact with
|
|
the page while a run is active.
|
|
- Representative and loaded scenarios should normally complete below five
|
|
seconds; every scenario must return within ten seconds. These are release
|
|
measurements, not CI timing assertions.
|
|
- Keep the copied report unchanged, including any incomplete outcomes or
|
|
hardware limitations. No mobile-device measurement is claimed by the source
|
|
tree until a human records it here.
|
|
|
|
The browser page uses the same `createPlanningCalculation(request)` context as
|
|
the calendar and adds no solver or backend dependency. The ten-second release
|
|
ceiling applies to planning latency; trace delivery is reported separately and
|
|
cannot replace a valid planning outcome.
|