Benchmark Results — 2026-09-02 (corrected baseline, read-path changes)

Re-run of the read-path benchmarks against dev@136877a5 plus the harness fixes in this branch, after the generated mapper changes of the same day. It supersedes benchmarks-2026-07-29.md for every number the README quotes.

BenchmarkDotNet v0.14.0, Windows 11 (10.0.26200.8457)
AMD Ryzen 7 7840HS w/ Radeon 780M Graphics, 1 CPU, 16 logical and 8 physical cores
.NET SDK 10.0.203
  [Host] : .NET 10.0.7 (10.0.726.21808), X64 RyuJIT AVX-512F+CD+BW+DQ+VL+VBMI
  Cold   : .NET 10.0.7 (10.0.726.21808), X64 RyuJIT AVX-512F+CD+BW+DQ+VL+VBMI
  Warm   : .NET 10.0.7 (10.0.726.21808), X64 RyuJIT AVX-512F+CD+BW+DQ+VL+VBMI
Command: dotnet run -c Release -f net10.0 -- --filter "*.Benchmarks.QueryBenchmarks.*"
         from benchmarks/Jaunty.Benchmarks
Global total time: 00:38:31, 264 benchmark cases

Headline: against a corrected baseline Jaunty is the fastest of the five libraries on SQL Server, and with WithExpectedRowCount on PostgreSQL and MariaDB it is within noise of the hand-coded loop. On SQLite the hand-coded loop is now the floor, 1.17x below Jaunty once the per-row FieldCount guard came out later the same day (1.33x before), and no library reaches it. Every "faster than ADO.NET" from the July reports was the baseline's GetDecimal round-trip.

What changed since the July report

Three things in Jaunty's read path and three in the harness. The read-path changes are in the CHANGELOG under Unreleased and told in full in How Jaunty got fast:

1. A decimal property on a column that reports double is read through GetDouble and cast, decided once per result set. On SQLite that is every REAL column.
2. The per-column IsDBNull pre-check ahead of non-nullable value types is gone; the named NULL error is produced from a catch instead (decision 010).
3. A custom mapper is handed to the row loop as given, without a wrapping delegate.

The harness fixes answer the validity findings the July report and a 2026-09-02 review raised:

Scope and caveats

• Read path only (Query<T> materialization). Bulk-copy suites are unchanged since July.
• Same laptop as the July runs, so ratios are comparable and absolute times are not. Nothing else was running on the machine during the run.
• Row counts 1 / 100 / 10,000. Warm-job rows only; cold rows are in docs/benchmark-artifacts/.
• SQL Server is a local instance; PostgreSQL and MariaDB are the docker-compose.yml containers on ports 5433 and 3307, in their own jauntybench databases.
• The custom-mapper cases with GetDouble are only meaningful on SQLite; on the other providers unit_price is a real decimal and Setup substitutes the GetDecimal mapper, so those rows duplicate the plain custom-mapper rows there and are omitted from the provider tables below.

Regression check vs 2026-07-29

Jaunty Query<T> mean as a ratio against hand-coded ADO.NET on the same run. Lower is better. The July column was measured against the uncorrected baseline, so on SQLite the two ratios are against different loops; the absolute Jaunty times are the like-for-like comparison there.

Warm job, 100 rows

Warm job, 10,000 rows

Read the SQLite column of this table with care. The run took 38 minutes on a laptop, the SQLite cases had standard deviations of 6-14% of the mean against 2-8% on the server providers, and within the column the generated mapper with a hint measured 2 ms slower than a hand mapper making the same reader calls, which three shorter runs the same day contradict. Sustained load on this machine drifts its clock down over ten minutes or more, and cases run at different points on that curve. The SQLite numbers the README quotes are from the separate run below.

Elsewhere in the table: WithExpectedRowCount beating the baseline on PostgreSQL and MariaDB is inside the run's noise and should be read as parity.

Why the unhinted Query<T> trails the hinted case by 3.7 ms on PostgreSQL and 1.4 ms on MariaDB. The GC columns of the summary say it: every unhinted case has Gen2 collections (62.5 per 1,000 operations on both providers) and every hinted case has none. A List<T> that starts at the default 64 doubles to 16,384 slots for 10,000 rows, and that last array is 131,072 bytes on 64-bit, over the 85,000-byte large-object threshold; new List<T>(10_000) is 80,000 bytes and never crosses it. Dapper, RepoDb and linq2db carry the same Gen2 signature. Confirmed the same evening by setting the default to 10,000 in the harness and re-running PostgreSQL at 10,000 rows: unhinted Query<T> 4,228 us, no Gen2, the hinted case's allocation. The default stays 64; the reasoning is in decision 012. EF Core's 100-row MariaDB case at 9 ms is ServerVersion.AutoDetect making a round trip inside the measured region, a harness cost, not a library one.

SQLite, 10,000 rows, measured alone

The same harness, the same day, SQLite and 10,000 rows only, after the machine had cooled: 3m37s for 22 cases. The README quoted this run until the guard removal below.

Two of the remaining 1.3 ms between the generated mapper and the hand-coded loop were known. The generated row mapper checked reader.FieldCount on every row as a guard against a stale delegate meeting a changed shape, and on Microsoft.Data.Sqlite that is a native call, about 0.4 ms per 10,000 rows; that guard is gone, and the section below is the run without it. The IsDBNull on the nullable product_name column stays, because NULL is a legitimate value there.

SQLite, 10,000 rows, after the FieldCount guard removal

Later the same day the per-row reader.FieldCount check was removed from the generated row mapper (decision 011) and the run above was repeated on the same harness: 3m40s for 22 cases. The 10,000-row SQLite rows in the README come from this run.

Jaunty Query<T> went from 5,417 us to 4,945 us; the hinted case's 705 us standard deviation makes its change unreadable. The log is tmp/bench-sqlite-10k-noguard.log in the private tree.

Allocation, 10,000 rows on SQL Server

Custom mapper, side by side, SQLite 10,000 rows

All four variants read the same five columns with the same typed getters; they differ only in the price getter and the list hint.

Method

BenchmarkDotNet spawns one process per (method, parameters, job), so each provider's RepoDb registration and Jaunty's static caches are fresh per case. The Cold job runs one invocation with no warmup and records first-call cost including cache population; the Warm job runs two warmup iterations and then 15 measured iterations. MemoryDiagnoser reports managed allocation per operation.

Earlier reports: benchmarks-2026-07-29.md, BENCHMARKS-2026-07-04.md.