Measured results¶

Cost is a property of the engine, not of the language. The rules in docs/ARCHITECTURE.md constrain what a file may say and would survive an engine swap untouched; what a build costs is settled here, by measurement. That separation is why this file can be rewritten by a benchmark run without anything in docs/SPEC.md moving.

Peak RSS and wall time for the same model built two ways — declaratively on the relational engine, and eagerly through linopy — from the same parquet files to the same destination. wall and peak columns are lpspec ÷ linopy: below 1.00 is a win for us. The chart page plots the same run.

The eager arm is lpspec.linopy.build, not hand-written linopy — our own YAML→linopy.Model shim, so it carries our loader on top of linopy's work. Against hand-written linopy on the same model the shim costs a constant ~2.3 ms: a fixed offset, nowhere near enough to move a conclusion.

Two sinks, and they are not the same comparison. The LP file is the artifact fewest callers want; highs is the one most reach for, and there HiGHS's own dense model is resident in both arms, which narrows every ratio. Read the sink you actually use.

How to reproduce it¶

Read straight off latest.jsonl and density.jsonl, each carrying the machine fingerprint, the library versions and the commit that produced it. Two files because a run replaces its output: one narrower than the tables it publishes would leave them unprovenanced while still looking complete.

uv run python -m bench.run --sizes xs s m l --repeat 3
uv run python -m bench.run --sizes d100 d50 d25 d08 --skip-gate --repeat 3 \
    --out bench/results/density.jsonl
uv run python -m bench.report bench/results/latest.jsonl bench/results/density.jsonl
uv run python -m bench.plot  # refreshes the chart page's numbers

Measure on an idle machine. An earlier version of these tables was taken while the laptop was doing other work and it inflated profiled by 55% — enough to turn "level" into "the one case we lose". Best of three, nothing else running.

Measured at 98f382d, on a clean tree. Each results file's fingerprint carries that hash, so a number on this page can be traced to the code that produced it — which is the whole point of committing the files. (density and scaling record it as 98f382d-dirty: they ran after latest.jsonl had been rewritten, and that file is tracked. The only modified paths were the earlier runs' own output.)

macOS-26.2-arm64-arm-64bit-Mach-O, python 3.13.2, 26 GB · lpspec 0.0.1a55 · polars 1.43.0 · linopy 0.8.0.post1.dev140+g346943317 (the v1-semantics build, PyPSA/linopy#717) · highspy 1.15.1 · numpy 2.5.1. Parity gate: all six cases agree to 0.0e+00 relative (fleet to 4.6e-16) before anything is timed.

The lpspec column here is the polars engine, not the default one. The run at 98f382d predates the current default, and a table says what the run that produced it did. On duckdb the numbers are worse, and bench/duckdb-spike.md says by how much: duckdb ÷ polars is 1.3–3.4× on build and 0.91–1.59× on peak. Re-taking this page with --arms lpspec linopy on an idle machine puts the default engine back in the column.

This lane replaced an out-of-tree duckdb engine, and the three-way comparison that decided it — speed against a settable memory ceiling — is in #189 and in git. The in-tree engine is a port of it and has never reproduced its memory advantage.

Results¶

dispatch — highs sink¶

Both arms end holding a populated highspy.Highs with run() never called: lpspec through build_highs, linopy through to_highspy(set_names=False). The simplex is the same work whoever filled the model, so timing it would say nothing about the lane that filled it.

variables	live	rows	wall: lpspec	wall: linopy	wall	peak: lpspec	peak: linopy	peak	LP
10k	100%	100	0.02 s	0.20 s	0.08x	0.17 GB	0.20 GB	0.86x	—
100k	100%	1k	0.02 s	0.21 s	0.10x	0.20 GB	0.21 GB	0.97x	—
1M	100%	10k	0.08 s	0.28 s	0.28x	0.50 GB	0.37 GB	1.34x	—
10M	100%	100k	0.57 s	1.03 s	0.56x	2.88 GB	1.97 GB	1.46x	—