Skip to content

The 1930th performance column, and every release beside it on one machine - #1204

Merged
Rafael-SOWNet merged 1 commit into
masterfrom
perf-1930
Sep 7, 2026
Merged

Rafael-SOWNet merged 1 commit into
masterfrom
perf-1930

Conversation

@Rafael-SOWNet

Copy link
Copy Markdown
Member

Release checklist item 3: a measured performance column for the current master (308384b2), with
every release from v2.1.0 to v2.4.0 re-measured on the same machine on the same day, nothing else
running. Documentation only.

What it says

since the 1915th since 2.4.0
SimplifyHard +0.18%, SolveHard +0.18%, SolveMediumHard +0.34% — to the digit the cost recorded for #1192; SimplifyEasy +360 bytes, unattributed; everything else flat SimplifyHard +0.84%, SolveMediumHard +0.65%, SolveHard +0.41%, SimplifyEasy +0.28%; compile rows inside their 2% floor; all inside the 3% gate

So the thirteen PRs after #1192 (#1191's codomain identity, the 29 growth declarations, the constant
fold, the graph-first collapse, bottom-up extraction) read as allocation-neutral on these benchmarks.
The section is explicit that this is two agreeing measurements and not a bisection: the commits
either side of #1192 were not re-measured, because an older commit builds from scratch and one such
run overran the ten minutes a single command gets in this session.

v2.4.0 measured a fortnight apart agrees to the byte on SimplifyHard and SolveMediumHard and
to 0.0005% on SolveHard, so the file's determinism claim holds again, with its rider on the
compile rows.

Timings are in the generated table and deliberately not in the document, per its 1844th section.

Part of #746.

🤖 Generated with Claude Code

https://claude.ai/code/session_012sonx8iAspMiwRwokT1Ura

…hine

The release checklist owes a measured performance column with the previous one
re-measured on the same machine. This is that column for 308384b: every release from
v2.1.0 to v2.4.0 and master, each measured on 2026-09-07 with nothing else on the
machine, one entry per run because a single command here is capped at ten minutes.

Since the 1915th, SimplifyHard is +0.18%, SolveHard +0.18% and SolveMediumHard
+0.34% -- to the digit the cost recorded for #1192 when it repointed the CanonicalOrder
sets at their data form -- so the thirteen pull requests after it read as
allocation-neutral on these benchmarks, and the section says that is a reading of two
agreeing measurements rather than a bisection. SimplifyEasy's +360 bytes is the one
figure that reading does not cover, and is left unattributed. Since 2.4.0, the pair a
release publishes, the Simplify and Solve family is up between 0.28% and 0.84%, the
compile rows sit inside their two-percent floor, and everything else is flat.

v2.4.0 measured twice a fortnight apart agrees to the byte on SimplifyHard and
SolveMediumHard and to 0.0005% on SolveHard, so the file's determinism claim holds
again with the same rider on the compile rows.

Part of #746, and item 3 of the release checklist.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012sonx8iAspMiwRwokT1Ura
@Rafael-SOWNet
Rafael-SOWNet merged commit 5408dc4 into master Sep 7, 2026
31 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant