29 lines
1.4 KiB
Markdown
29 lines
1.4 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, asynchronous calculation, and total wall
|
|
time separately. It records the outcome, last completed quality stage,
|
|
placement count, and determinism between repetitions. `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 `planLeave(request)` operation as the calendar
|
|
and adds no solver or backend dependency.
|