Performance
Python measurements by release
Full request lifecycles, measured separately from native core microbenchmarks.Each release uses its own engine and binding. Every available case supplies 7 or 93 facts, solves, checks the expected answers and closes the result. Symbols and integers, convenience solve and prepared sessions are separate cases. V1 releases without prepared sessions explicitly report that case unavailable.
Both profiles use -O2, the same Python interpreter and fixed CFFI tooling. Warm passes contain 501 samples after 50 warmup requests. Cold seven-symbol cases collect the first request in 31 fresh interpreters, excluding import and policy compilation. Phase timings come from separate transactions and cannot be paired with total-loop samples.
All chronological samples, including slow tails, are retained with contemporaneous CPU/resource/GC telemetry. Minimum is primary below 10 µs; otherwise median, with p95 shown separately. Four A/A passes precede forward/reverse rounds. A three-request control on the latest binary checks coarse sensitivity only.
The charts use the same presentation as the native explorer, but only Python measurements. Read the symbols and integers separately, and compare convenience solve with a prepared session at the same fact count. Each chart explains the selected phase below its curves; exact values and noise floors remain available in the expandable panel.
v0.12.0 · SMALL · Round 1 · forward · Complete request · -O2
Measurement details — pass and statistic
Retained uses the minimum for cases below 10 µs in A/A, and the median otherwise. Every chart shows one individual pass; nothing is pooled. Fixed-statistic views are available for inspection, not a new acceptance rule.
Methodology and provenance
python-individual-release-campaign-v1 · MAC-QXQWJGVJXW · arm64 · -O2 · local Mac measurements; no priority or affinity tuning.
Python V · loading binding identity. The binding shipped at that tag is measured. V1 and V2 have different implementations; their labels do not establish interchangeable API costs.
The latest binary’s fixed three-request control was detected in every declared case/profile and both rounds. This establishes coarse sensitivity only, not sensitivity to small effects.
Loading measurements…
Exact values and A/A noise floors
How to read the values
µs means microseconds: 1 µs is one millionth of a second. A chart point times the complete workload at its labelled size. It is not automatically the cost of one fact or one solve.
- min · primary
- Minimum is the fastest recorded sample. Primary marks the statistic retained for reading that case; it is not another measurement. Here minimum is primary for cases classified below 10 µs in A/A; median is primary otherwise. A minimum is not a guaranteed best response time.
- median
- Sort the samples from fastest to slowest. The median is the middle: half are at or below it, half at or above. It describes typical measured time, not the arithmetic average.
- p95
- 95% of the pass’s samples are at or below this time; the remaining 5% may be slower. Use it to see the slower end of the measurements. It is neither the maximum nor a worst-case guarantee.
- A/A floor · minimum
- This is the repeatability floor for the minimum, in percent, not µs. The same unchanged binary is run again in two A/A pairs; the larger relative gap is retained. Each statistic has its own floor. This last column repeats the floor of the case’s primary statistic.
For example, an A/A floor of 5% means that unchanged runs differed by that much for this statistic. An observed 3% difference stays indeterminate: it is not a win, a loss or proof of equal performance. A floor of 0% only says these recorded pairs agreed; it does not certify that all noise is zero. A/A is not a confidence interval.
Python protocol and earlier hosted observations · Separate native release measurements