Repository navigation
Add acceptance test that fails when a package init() is slow - #7406
Conversation
| @@ -0,0 +1 @@ | |||
| OK: package init times are within threshold | |||
There was a problem hiding this comment.
Is it a good idea to record the packages as well (sorted, without timings), to track what's happening in init? or will it add too much churn?
There was a problem hiding this comment.
Good idea. Latest has a copy that should be ~stable and not introduce much churn.
Please take a look.
|
Commit: Regression test reportSelected 1 changed tests (limit=20, 0 not selected) 1 tests: regression=0 unreleased=0 coverage=0 failing=1
TestAccept/inittime: branch ❌ | main (9605618) ✅ | latest (v1.25.0) ✅branch: |
✅ Integration test reportCommit: 96b9183
Top 3 slowest tests (at least 2 minutes):
|
5467189 to
c46add8
Compare
go-runewidth v0.0.26/v0.0.27 filled a 2 MB table in init(), adding ~20 ms to every CLI invocation. It arrived through a transitive Charm upgrade and went unnoticed (fixed in #7391). The new acceptance test runs `$CLI --version` with GODEBUG=inittrace=1 and fails if any package's init clock exceeds 5 ms. Each package is judged by its minimum over 5 runs, extended up to 20 runs while a check fails, so load from parallel tests does not cause flakes while a real regression fails on every run. It also records a per-package init time budget in out.initlimits.txt, initialized at 4x the measured minimum (at least 0.1 ms; unlisted packages get 0.1 ms). A package that exceeds its budget gets a new one, so several- fold slowdowns show up as a diff in review without flaking on noise. The test runs on linux/amd64 only: Windows inittrace clocks can be quantized to the system tick, and the set of packages with an init differs per architecture. Co-authored-by: Isaac <no-reply@databricks.com>
c46add8 to
2dc7448
Compare
Co-authored-by: Isaac <no-reply@databricks.com>
Co-authored-by: Isaac <no-reply@databricks.com>
Co-authored-by: Isaac <no-reply@databricks.com>
| f"FAIL: package init() takes {total:.2f} ms in total, over {args.max_ms:g} ms; this delays every CLI invocation." | ||
| ) | ||
| print("To investigate:") | ||
| print(" GODEBUG=inittrace=1 databricks --version 2>&1 | sort -k5 -n -r | head") |
There was a problem hiding this comment.
should we just run it here and record output? For historical runs. Can also drop sort and head.
There was a problem hiding this comment.
WDYM for historical runs?
We already capture the timing in the log output.
There was a problem hiding this comment.
Can do it in a follow up if we need to.
Changes
New acceptance test
acceptance/inittimeruns$CLI --versionwithGODEBUG=inittrace=1and:init()clock time toLOG.inittime, sorted slowest first, on all OSes;Times are minimums over 5 runs (extended to 20 while the total is over the threshold), so load from parallel tests doesn't cause flakes. The threshold is not enforced on macOS and Windows, where clocks are too coarse or noisy (Windows can quantize to the ~15.6 ms system tick).
Example log (linux/amd64, truncated):
Why
go-runewidth v0.0.27 arrived through a transitive Charm upgrade and added ~20 ms to every invocation, unnoticed until #7391. Checking the total rather than individual packages also catches a slow drip of small regressions, and the log shows which packages contribute.
Tests
--max-ms 3the check fails:FAIL: package init() takes 5.27 ms in total, over 3 ms.This pull request and its description were written by Isaac.