Repository navigation
test(perf): scale the nightly limits by how fast the runner is (#159) - #160
Merged
Merged
Conversation
The nightly perf job failed on slower GitHub runners with unchanged code. The run now times a fixed reference workload first: pure JS, plain SQL and an exact vector scan, none of it Kept's code. Every millisecond limit in test/perf is multiplied by the speed factor, clamped to [1, 3]. The reports and failure messages print the factor and the scaled limit. A regression still fails, because the reference work doesn't slow down with the code. The reference values are inferred from a local M1 Pro run and the snapshot bench's M1 Pro-to- EPYC 9V45 ratio. Re-pin them from a fast night's calibration.json. Closes #159 Signed-off-by: Ibrahim Roshdy <22573766+ibrahimroshdy@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #159.
The nightly perf job failed on slow runners, not slow code. The CPU model the snapshot bench prints matches the result every night: the EPYC 9V45 passed on Oct 10 and 12, and the EPYC 7763 (four nights), 9V74 and Xeon 8573C failed with unchanged code. Now the run times the runner first, and every millisecond limit in
test/perfscales with how slow it is.How it works
test/perf/global-setup.ts(a second global setup invitest.perf.config.ts) times a fixed reference workload once, before any file runs. None of the workload is Kept code (test/perf/calibrate.ts):normalize. A checksum pins it.under()intest/perf/limits.ts).searchSemanticP95Ms: 520 ms against 300 ms × 1.68 (runner speed) = 504 ms. Each file's JSON getscalibration, plus alimitsentry per check (measuredMs,limitMs,factor,scaledLimitMs,pass)..tmp/perf/calibration.jsonholds the raw timings.rls.bench.ts) is not scaled. Its budgets are §3.1's, and the slowest night used about 28% of them.The reference values are inferred, not measured on a runner.
REFERENCE_MSshould be the 9V45's timing, but the workload is new, so nothing has measured it there yet. It is the M1 Pro's timing from a full local perf run, divided by 1.42. That is how much slower the M1 Pro was than the 9V45 at the same fixed work in the same run: the snapshot bench's full snapshot as owner, p50 453.5 ms locally against 327.2 / 311.5 ms on Oct 10 / 12. Re-pin it from the first 9V45 night'scalibration.json.Tested
test/perf-calibration.test.ts(normal suite, 11 tests) covers:bash scripts/ci-local.sh --only perfran once locally, on an M1 Pro at load 10–26 from other runs, so its figures are not evidence. Calibration: cpu 273.1 / db 626.9 / vector 401.8 ms. That run used a provisional reference (the M1 Pro's own earlier probe), so its factor was 1.12, and 19 of 20 checks passed. The one failure was the notification count, p95 24.9 ms against 20 × 1.12 = 22.4 ms. Under the reference pinned here, that run's factor would have been 1.42 (limit 28.4 ms).ci-local.sh --only lint,typecheck,driftandcheck-i18npass.things/move.test.ts"200 things in under a second" (1,898 ms; 1,194 ms on a rerun) andfiles/pdf-text.test.ts(a runaway PDF hittimeoutbeforememory; it passed on a rerun).