Performance

Native performance by release

Loading, interning and solving — choose a release and profile.

Choose a release and SMALL or LARGE. Each chart shows one workload: read its input size and legend, then compare the curves at the same input. Lower times are faster.

The notes below each curve explain its workload and the selected results. Go to the measurements · Measurement methodology · Exact values and statistical definitions

Measurement methodology

These are recorded native C measurements, not benchmarks running in your browser. The September 27 campaign rebuilt all 18 published release tags, for SMALL and LARGE, with one common benchmark and one Clang toolchain on the same local Mac.

Build first, measure afterwards. Every release/profile binary is compiled once at -O2. All builds finish before timing begins; native and Python campaigns run separately, not concurrently.
Warm up the workload. Before capturing each case, the benchmark executes it for at least 500 warmup iterations and at least 300 ms. These are warm measurements, not process startup or a cold first request.
Capture repeated samples. Each case and pass contains 1,000 samples. Short workloads use calibrated repetitions; each sample is their total timed work divided by that repetition count. Chronological samples, including slow observations, are retained. Nothing is removed because it looks slow.
Measure the unchanged binary first: A/A. Runs AA-1/AA-2 form one pair and AA-3/AA-4 another. For each case and each statistic, retain the larger relative difference of those two pairs as its observed repeatability floor. For example, unchanged minima of 1.00 and 1.05 µs give a 5% relative gap.
Then run two separate rounds. Round 1 visits releases from oldest to newest; Round 2 reverses that order. Select either round to inspect it. Their samples and percentiles are never pooled or averaged together.
Choose a statistic before interpreting a gain. The median of the four A/A medians classifies each native case: below 10 µs its minimum is primary; otherwise its median is primary. p95 remains available to inspect slower samples. A fixed-statistic view helps inspection but does not change that recorded rule.

What is inside the timed operation?

Interning and insertion charts time the complete group at the labelled size. Input preparation is outside the timer.
Input sizes count supplied entries before finalization, not necessarily distinct facts afterwards. The dense-join axis counts users, and the repeated-solve axis counts evaluations instead.
Solver charts include input finalization, core solve/result creation, the expected membership check where applicable, and result release. Policy parsing and initial input construction are outside the timer.
These core workloads do not time the opaque SDK session lifecycle, Python/CFFI conversions, JavaScript/WASM, network I/O or your whole application.
The native p95 describes measured samples; a short sample can average several calibrated workload repetitions. It is not a promise about the p95 of individual production requests.

Recorded compiler: Apple clang version 21.0.0 (clang-2100.1.1.101)
Recorded system: macOS-26.6.2-arm64-arm-64bit-Mach-O
Build flags: -std=c11 -Wall -Wextra -g -O2
Host controls: No priority, affinity or QoS tuning; no native core case discarded.

The selected dataset’s exact commit, machine and compiled capacities are in Methodology and provenance. Raw samples, all six passes, the captured benchmark source and the comparison report are available from the explorer’s download links.

Interpret a result, not just a speed factor

Compare the same work.: Unit and batch must use the same fact count and value shape. A dense join and a sparse join are different inputs, not competing implementations.
A speed factor is not a time-saving percentage.: As an arithmetic example, reducing a group from 10 to 9 µs makes the old path 1.11× as long, but saves 10% of its time, not 11%. The saving uses the unit path as its baseline; the relative-gap line uses larger time / smaller time − 1, as in A/A. These example times are not values for the selected release.
Read the noise floor.: The batch notes use the larger A/A floor of the two cases for the selected statistic. A relative gap at or below that floor is indeterminate, not zero or a demonstrated gain.
Read the other round and p95 too.: A lower minimum does not mean that the typical or slower samples improved. Ratios describe the displayed pass, not a pooled result or a guarantee that both rounds agree.
Keep the scope local.: Even an above-floor gap does not identify its algorithmic cause. The native campaign has no injected positive control; A/A alone does not certify sensitivity to every small effect or differences in binary placement.

Profiles and memory are different questions

SMALL and LARGE choose bounded capacities, not different Datalog semantics or a speed ranking. The compiled capacities are shown for the selected release. Match both the profile and those capacities when comparing releases; a profile name alone is not enough.

A chart point is execution time. It is not bytes reserved by a session, allocation count or process memory (RSS). A smaller reservation does not establish faster solving. The session-memory comparison and older chart captures remain available separately; their old timing protocol must not be attributed to this campaign.

The selected release is the one measured, not necessarily the runtime version currently served by the site. Changing this selector does not change that runtime; promoting a runtime does not create new measurements.

Python release measurements use their own binding, lifecycle and protocol. They do not fill or explain a point on these native curves. See Runtime EDB for batch semantics and the topical API references for application calls.

Measured results

Release Profile Updating measurements…v0.12.0 · SMALL

v0.12.0 · SMALL · Round 1 · forward · -O2

Measurement details — pass and statistic

Pass 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

native-core-release-campaign-v1 · MAC-QXQWJGVJXW · arm64 · -O2 · local Mac measurements; no priority or affinity tuning.

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.