k4bench.regression.history¶
k4bench.regression.history ¶
Release-level history tails for the metrics the report confirms.
A confirmed step is one number — "+21%" — and a number on its own cannot be told apart from the series it came out of. A metric that holds ±0.4% for two weeks and then moves 21% has almost certainly been changed by something; a metric that swings 20% every third release has not said anything at all. The verdict carries the step; this module carries the series, so whoever has to explain the step (the blame ranker, a human reading the dashboard) can see both.
The unit is the release, matching :mod:k4bench.regression.engine: nights
sharing a run_date re-measure one software state, and pooling them into one
point is what keeps a stack that did not move from looking like a metric that
wobbled. Every point states how many nights it aggregates and how many of those
were actually judged, because "measured and flat" and "recorded but never
assessed" are different evidence and only one of them is a control.
Nothing here judges anything. The engine has already decided what each night was; this is a bounded, chronological read of that decision.
host_facts ¶
host_facts(machine_df: DataFrame | None) -> dict[str, HostFact]
run_id -> the machine that ran it, from the machine-info trend.
Runs with no machine info simply have no entry: a history tail that cannot name the host says nothing about it, which is not the same claim as "the host never changed".
Source code in k4bench/regression/history.py
release_points ¶
release_points(history: DataFrame, verdicts: Sequence[MetricVerdict], *, hosts: dict[str, HostFact] | None = None) -> tuple[ReleasePoint, ...]
One :class:~k4bench.regression.models.ReleasePoint per release in
history, oldest first.
history is the frame :func:~k4bench.regression.engine.evaluate_series
walked (run_id, run_date, value, reliable) and verdicts is
what that walk returned. Both are needed, and neither substitutes for the
other: the frame is the only record of the nights the engine skipped (an
unreliable host produces no verdict at all), while the verdicts are the only
record of what the nights that were judged meant. Reading the level off the
frame alone would let a contended night set a release's level; reading it off
the verdicts alone would silently drop those releases from the tail, which
reads as a stack that was never benchmarked.
hosts (from :func:host_facts) names the machine behind each run_id,
so the tail can show a change of benchmark host next to the change in the
number. Omit it and the points simply carry no host.
Ordered and grouped exactly as the engine orders and groups — same sort, same
:func:~k4bench.regression.engine.release_key — so a point here can never
describe a release the walk drew differently.
Source code in k4bench/regression/history.py
93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 | |
history_tail ¶
history_tail(points: Sequence[ReleasePoint], *, upto: str | None = None, limit: int = HISTORY_RELEASES) -> tuple[ReleasePoint, ...]
The last limit points at or before release upto.
Cut at upto rather than at the end of the series because a verdict is
issued for a release, and a nightly run can re-measure an older one: the
tail a verdict carries must be the history that existed when it was issued,
or a re-benchmark would ship a verdict annotated with releases that came
after it. None takes the tail as it stands.
The cut is made on position where the release is in the tail, and only falls back to comparing keys when it is not: the points are already in the engine's order, and an undated release keys on its run id, which orders against a date by nothing more than luck.