The profile section in docs/contributing/benchmarks.md says how to run scripts/bench/boot-profile.ts, what the profile of the v1.44 runtime found (the worker graph as one 753 ms block, a live heap of about 165 MB of which the query compiler holds 50 and the catalogs 33) and what changed. scripts/bench/results/v1.45.0-*.md hold the before and after numbers per area, from back-to-back runs on the same machine. The size baselines take the lowered numbers.
1.5 KiB
v1.45.0: workout duplicate window
A correctness change, not a speed one; the request benchmark does not read workouts, so there is no latency row for it.
Before: two copies of one session were collapsed only when both starts fell
in the same fixed five-minute clock slot (floor(start / 5 min)). A pair 30 s
apart that straddled a slot boundary stayed two workouts in the list, the
batch write, the calendar, strain and the Coach.
After: per user and sport, sorted by start, a workout joins the open cluster while it starts less than five minutes after the cluster's first start.
Proof (src/lib/measurements/__tests__/pick-canonical-workout-rows.property.test.ts,
against the previous picker kept as pick-canonical-workout-rows.legacy.ts):
| property | inputs |
|---|---|
| same rows as the fixed slots wherever no pair within five minutes straddles a slot boundary, three ladders | 4,000 generated inputs, over 1,000 comparable |
| same strain impulses as before on those inputs | 2,000 generated inputs, over 500 comparable |
| two sources' copies collapse at any offset under five minutes (the old picker missed a share) | 3,000 random offsets |
| five minutes or more apart never collapse | 2,000 |
| a uniform shift of every start keeps the picked set | 1,500 |
| a row of workouts four minutes apart does not chain | fixed case |
One existing case changed its expectation: three runs at 08:04, 08:08 and 08:12 used to stay three because they sat in three slots; 08:08 is now the 08:04 run from a lower-ranked source (four minutes apart), and 08:12 stays.