strawmANN benchmark report

strawmANN against Qdrant · AMD Ryzen AI 9 HX PRO 370 w/ Radeon 890M (24 logical) · generated 2026-09-29 10:29:45 CEST

Dataset: h-and-m-2048-angular-filters
Vectors: 105,100 × 2,048 · 10,000 held-out queries
Metric: cosine
Storage datatype: strawmANN float32 · Qdrant float32 (default)
Quantization: none (fp32) · separate rows measure binary (1 bit/dim), PQ (product), SQ8 scalar

strawmANN: 43/43 ok Qdrant: 43/43 ok

Summary

At equal recall, strawmANN serves 1.30x to 1.66x Qdrant's throughput. That range spans the recall levels measured; allowing for the uncertainty in each recall figure widens it to 0.72x to 2.61x.

throughput at equal recall

1.30 to 1.66x

strawmANN over Qdrant, recall@10 0.994 to 0.999

p99 latency at 90% load

strawmANN2.57 ms

Qdrant8.26 ms

W4-sat90, open loop, each engine's own saturation

upload and index build

strawmANN24 s

Qdrant26 s

W1 + W2

peak memory (RSS)

strawmANN5.6 GiB

Qdrant8.6 GiB

largest before the concurrent-write rows (W11); of it, anonymous 609.2 MiB / 550.4 MiB

written to disk

strawmANN4.8 GiB

Qdrant22.3 GiB

before the concurrent-write rows (W11); they wrote 205.8 MiB / 31.6 GiB more

Where strawmANN is slower, past the noise floor:

search, saturating (closed loop) (W4): 0.82x, strawmANN at recall 0.9986, Qdrant at 0.9970
recall/latency frontier (W10-ef128, W10-ef256, W10-ef512, 3 settings): 0.88 to 0.97x
filtered search, one keyword (~1% of bench12) (W12-sel1-ef32, W12-sel1-ef64, 2 settings): 0.57 to 0.75x
filtered search, any of 10 keywords (~10% of bench12) (W12-sel10-ef256, W12-sel10-ef512, 2 settings): 0.52 to 0.85x

Throughput against recall

Read it vertically: at any recall both engines reach, the higher curve is faster. Throughput from bfb W10, recall from the conformance sweep, joined on ef. ef is the same unit here: Qdrant held 2 segments for this run, one populated and 1 empty (read back per segment from the engine), and strawmANN held one graph, so equal ef is equal traversal width and the curves may be read at equal x. That is a property of this run, not of the engines.

Every figure is the median of 3 passes per engine, run alternately (A/B/A/B). What this does not establish.

Glossary

recall@10: Of the ten nearest neighbours a query really has, the share the engine returned. 1.0 is a perfect answer. "Really has" is settled by an exhaustive fp64 search, not by the other engine.
ef: The candidate-list size: how many nodes the index keeps in play while searching. Larger is slower and more accurate. It does not mean the same amount of work in both engines, which is why the headline holds recall fixed instead.
MRDE: Mean relative distance error: when the engine returns a wrong neighbour, how much further away it is than the right one. Small numbers mean the misses were near-misses.
qps: Queries per second. On a batched row one request carries several queries, and the request rate is shown under it.
p50 / p99 / p99.9: The latency half of requests beat, that 99% beat, that 99.9% beat. The tail is what a user notices.
closed / open loop: A closed loop sends the next request only when the last one comes back, so a slow server receives less work and its tail looks better than it is. An open loop sends at a fixed rate regardless.
noise floor: How much a number moves between identical runs on this machine. A ratio inside it is shown grey with ≈: no measured difference. Hover a ratio to see its band.
conformance tier: What the two engines were shown to agree on before any speed was quoted. T1 licenses a single engine's own numbers; T3 licenses comparing the two, and requires their recall to be statistically indistinguishable.
§ numbers: Sections of docs/spec.md, the written rule each claim in the appendix is measured against. §7.1 is the host gate, §7.4 the comparison rules, §8 what may be published.

Throughput

Queries per second; higher is better. The ratio is strawmANN over Qdrant: green is faster, red slower, grey ≈ inside the noise floor (hover a ratio for its band). A dash means the pair is not compared, and the note says why. An ef sweep is one row showing its range; every measurement is under All throughput rows.

workload		strawmANN	Qdrant	ratio	notes
W3	search, fp32, single query	1,281	986	1.30x
W4	search, saturating (closed loop)	4,656	5,683	0.82x
W5	search batched (16 distinct dataset queries per request)	4,656291 requests/s	2,164136 requests/s	2.15x
W6	quantized: scalar	3,621	2,726	1.33x
W6 ef 32 to 512	SQ8 recall control (latency only)	1,423 to 7,619	1,005 to 5,268	1.27 to 1.45x
W7	quantized: binary + oversampling	4,352	4,354	parity
W8	quantized: PQ	1,452	1,121	1.30x
W9	exact / brute force	71	71	parity
W10 ef 32 to 512	recall control (latency only)	1,731 to 11,967	1,959 to 10,428	0.88 to 1.15x
W12-sel1	filtered search, one keyword (~1% of bench12)	2,594	2,503	parity
W12-sel10	filtered search, any of 10 keywords (~10% of bench12)	1,147	1,280	parity
W12-sel1 ef 32 to 512	filtered recall control, one keyword (latency only)	2,593 to 2,612	1,137 to 4,599	0.57 to 2.29x	1 of 5 points not compared
W12-sel10 ef 32 to 512	filtered recall control, any of 10 keywords (latency only)	408 to 2,583	486 to 2,998	0.52 to 0.85x	3 of 5 points not compared recall differs
W13	scroll / pagination	50,845	46,450	1.09x	strawmANN: 92% is client and socket, not server Qdrant: 82% is client and socket, not server
W11-steady	mixed read/write below the rebuild threshold: search bench2 while 5,255 synthetic points append	2,388	3,857	-	search-during-write; no recall join
W11	mixed read/write: search bench2 while 21,020 synthetic points append (runs last)	623	3,453	-	search-during-write; no recall join

Throughput by workload

Higher is better. Hatched bars are rows the table does not compare (W7, W9, W11): each bar is that engine's own rate, and the pair is not a result.

Recall

recall@10 against an exact fp64 search, not against the other engine. Equal ef is not equal work in the two engines, so the comparison that counts holds recall fixed and compares throughput there.

At matched recall

recall@10	measured at	strawmANN q/s	Qdrant q/s	strawmANN / Qdrant	range over recall CI
0.9943	strawmANN at ef=32, Qdrant interpolated	11,967	7,193	1.66x	1.50 – 1.85x
0.9945	Qdrant at ef=64, strawmANN interpolated	11,713	7,141	1.64x	1.21 – 2.22x
0.9970	Qdrant at ef=128, strawmANN interpolated	7,740	4,791	1.62x	1.33 – 1.96x
0.9972	strawmANN at ef=64, Qdrant interpolated	7,476	4,519	1.65x	1.20 – 2.27x
0.9985	Qdrant at ef=256, strawmANN interpolated	4,733	3,120	1.52x	1.12 – 2.05x
0.9986	strawmANN at ef=128, Qdrant interpolated	4,636	3,006	1.54x	0.91 – 2.61x
0.9992	strawmANN at ef=256, Qdrant interpolated	2,852	2,110	1.35x	0.87 – 2.11x
0.9993	Qdrant at ef=512, strawmANN interpolated	2,541	1,959	1.30x	0.72 – 2.35x

How this is computed

Interpolated linear in log(q/s) between the two bracketing measurements, nothing extrapolated past the measured range. Throughput is bfb's W10 sweep, recall the conformance sweep, joined on ef — same m and ef_construct, but separate builds, so the pairing assumes two builds with identical parameters are equivalent.

The last column is why the ratio is not a result on its own. The ratio treats the anchor's recall as exact; it is an estimate, and moving it across its 95% interval moves the interpolated rate with it — near the top of the sweep 0.003 of recall spans a factor of 1.8, so two decimals there quote the interpolation. Even that is the narrow reading: it moves one recall and not the other, adjacent anchors share bracketing segments, and the throughputs behind it are medians of the run's passes.

At matched recall, SQ8

The same reading over the scalar-quantized collection. Under the `pool` policy both engines rescore `ef` candidates, so W6 is compared row by row as well; held at equal recall, the reading does not depend on the rows landing in one recall band. Note where each engine's curve stops, because a recall only one of them reaches is the more useful fact about an encoding than any ratio.

recall@10	measured at	strawmANN q/s	Qdrant q/s	strawmANN / Qdrant	range over recall CI
0.9947	strawmANN at ef=32, Qdrant interpolated	7,619	4,003	1.90x	1.74 – 2.09x
0.9948	Qdrant at ef=64, strawmANN interpolated	7,509	3,985	1.88x	1.42 – 2.49x
0.9974	Qdrant at ef=128, strawmANN interpolated	5,177	2,731	1.90x	1.58 – 2.28x
0.9975	strawmANN at ef=64, Qdrant interpolated	5,058	2,572	1.97x	1.14 – 3.39x
0.9986	Qdrant at ef=256, strawmANN interpolated	3,910	1,734	2.26x	1.81 – 2.81x
0.9989	strawmANN at ef=128, Qdrant interpolated	3,615	1,365	2.65x	1.18 – 5.94x
0.9993	Qdrant at ef=512, strawmANN interpolated	2,730	1,005	2.72x	1.62 – 4.54x

How this is computed

Interpolated linear in log(q/s) between the two bracketing measurements, nothing extrapolated past the measured range. Throughput is bfb's W6 sweep, recall the conformance sweep, joined on ef — same m and ef_construct, but separate builds, so the pairing assumes two builds with identical parameters are equivalent.

The last column reads as it does in the fp32 table above.

At matched recall, filtered to 10%

The same reading under a keyword filter over the points the condition matched, 10,608 in strawmANN and 10,565 in Qdrant (bfb draws the keyword payloads unseeded at each upload). The per-row table refuses W12-sel10 a ratio because the two engines land just outside the recall band at the one ef it measures; held at equal recall instead, the comparison exists at every recall both engines reach. Note the shape rather than any single number: one engine's curve is flat in ef and the other's is steep, so where you match decides the ratio.

recall@10	measured at	strawmANN q/s	Qdrant q/s	strawmANN / Qdrant	range over recall CI
0.9929	strawmANN at ef=32, Qdrant interpolated	2,583	1,320	1.96x	1.87 – 2.04x
0.9952	Qdrant at ef=128, strawmANN interpolated	2,138	1,268	1.69x	1.45 – 1.96x
0.9975	strawmANN at ef=64, Qdrant interpolated	1,761	959	1.84x	1.56 – 2.17x
0.9991	strawmANN at ef=128, Qdrant interpolated	1,146	797	1.44x	1.28 – 1.61x
0.9992	Qdrant at ef=256, strawmANN interpolated	992	784	1.26x	0.59 – 2.71x
0.9999	Qdrant at ef=512, strawmANN interpolated	482	486	0.99x	0.65 – 1.50x

How this is computed

Interpolated linear in log(q/s) between the two bracketing measurements, nothing extrapolated past the measured range. Throughput is bfb's W12-sel10 sweep, recall the conformance sweep, joined on ef — same m and ef_construct, but separate builds, so the pairing assumes two builds with identical parameters are equivalent.

The last column reads as it does in the fp32 table above.

Recall by `ef`

ef	strawmANN				Qdrant
ef	recall@1	recall@10	recall@100	MRDE	recall@1	recall@10	recall@100	MRDE
ef=32	0.9978	0.9943	-	1.25e-03	0.9956	0.9877	-	1.75e-03
ef=64	0.9990	0.9972	-	6.72e-04	0.9980	0.9945	-	7.16e-04
ef=128	0.9996	0.9986	0.9923	3.47e-04	0.9992	0.9970	0.9866	4.52e-04
ef=256	0.9996	0.9992	0.9975	3.14e-04	0.9995	0.9985	0.9959	1.62e-04
ef=512	0.9998	0.9997	0.9993	4.57e-05	0.9996	0.9993	0.9984	1.36e-04

How recall was measured

10,000 held-out queries, limit 10, ε=6.556510925292969e-07, against the fp64 oracle rather than against the other engine. Base checksum 5a7faba68c84ce7c: the same corpus the latency rows were measured on. Each pass rebuilds the collection. Across 3 independent builds of it, recall@10 at ef=512 spread by: strawmANN 0.00016; Qdrant 0.00012. Over the same builds the engine reported unreachable nodes: strawmANN 0 of 127,843 — a node nothing points at is invisible at any ef, so that is where a graph-quality difference shows rather than being inferred from the recall beside it. Level seed: strawmANN 0x57ea3111. Recorded as provenance: under this engine's level draw, six builds at four seeds sit within 0.00003 of recall@10 at ef 512, well inside the spread above.

What each quantization costs in recall

Colour is the encoding here, not the engine — the engines are the line style. Each sweep is joined on the quantization parameters it actually sent, so a curve speaks only for the search its row ran. Higher is better, and the encodings are not free: read this against the throughput their rows bought.

Latency

Client-side round trip. A closed loop understates the tail (a stalled server stops receiving requests), so this keeps the fixed-rate, open-loop rows, which offer the same load to both engines, plus single-client W3 and batched W5. Every row is under All latency rows.

Not compared. The open-loop rows were offered different rates on the two engines (W4-sat50, W4-sat70, W4-sat90): each is a fraction of its own engine's measured saturation, so the two columns are the same fraction of capacity and not the same load. Read the fraction across, never the percentiles. Pin one reference with workloads.py run … --rps-reference <qps> — the slower engine's saturation — to make them comparable.

workload	strawmANN			Qdrant
workload	p50	p99	p99.9	p50	p99	p99.9
W3 search, fp32, single query	759 µs	1.40 ms	1.73 ms	1.00 ms	1.43 ms	1.54 ms
W4-sat50 search, fixed rate at 50% of saturation (open loop)	889 µs	1.57 ms	1.80 ms	1.12 ms	2.09 ms	2.49 ms
W4-sat70 search, fixed rate at 70% of saturation (open loop)	1.01 ms	2.12 ms	2.47 ms	1.30 ms	2.65 ms	3.56 ms
W4-sat90 search, fixed rate at 90% of saturation (open loop)	1.15 ms	2.57 ms	3.51 ms	1.91 ms	8.26 ms	13.36 ms
W5 search batched (16 distinct dataset queries per request)	6.86 ms	8.12 ms	8.55 ms	14.78 ms	16.64 ms	17.30 ms

Ingest and index build

Qdrant indexes while it ingests, so its upload time already contains most of the indexing; strawmANN uploads raw and builds afterwards. Compare the sum, not the upload line.

Where the load time goes

Solid is upload, hatched is the wait for Green. The bar's whole length is the sum this section asks you to compare; the split is why the upload line alone is not comparable between these engines.

workload		strawmANN	Qdrant
W0-upload	d=4 floor: graph traversal with the distance taken out	4.01 s	4.01 s †
W1	ingest throughput (no index wait)	1.04 s	2.57 s
W2	index build, time to Green	23.08 s	23.06 s
W6-upload	search, SQ8 scalar quantization	85.20 s	19.05 s
W7-upload	search, binary quantization	25.08 s	11.03 s
W8-upload	search, product quantization	173.56 s	145.37 s
W12-upload	upload	23.07 s	44.11 s
W1 + W2	upload and index, together	24.1 s	25.6 s	1.06x

† at the load generator's polling floor. bfb decides a collection is Green by polling once a second and requiring three consecutive Green replies, having slept a second before the first poll, so no Time-to-Green it can report is below 3 s regardless of how fast the build was. A marked cell is an upper bound on the build and a measurement of the polling loop. The bias is a constant added to both engines, so the difference between them survives it and the ratio does not — and it is the faster engine the ratio understates.

Memory and disk

What each engine held in memory and moved to and from disk over the whole run. Per-row figures are under Storage and I/O.

	strawmANN	Qdrant
storage on disk	6.0 GiB	4.6 GiB
peak memory (RSS)	5.6 GiB	8.6 GiB
read from disk	20.0 KiB	282.4 MiB
written to disk	4.8 GiB	22.3 GiB

Peak memory and storage on disk are read before the concurrent-write rows (W11): an engine rewriting segments maps old and new files at once, and RSS counts each mapping. Bytes written are summed over the same rows, since W11's volume is set by the harness's write rate; the other disk figures are totals over every row.

Appendix

How the run was set up, every row of every table, and the diagnostics behind them. Charts on a logarithmic axis say so on the axis: read the positions there, not the distances.

Run conditions and conformance

Measured as-deployed: the scheduler was left as it ships, so a difference is what a user would see rather than the engine in isolation, and ambient load is part of the measurement. Qdrant ran equal-work: asked for one populated graph (--segments 1), as strawmANN serves, so ef means the same thing on both sides. This is the configuration §8's comparative licensing is built around, and it is a control rather than a deployment. Its optimizer treats the count as a target; what it actually held is read back from the engine and stated under Collection config.

Conformance tier reached: T4 quantization fidelity. T1 passed, so single-engine performance rows are licensed (§8). T3 passed, so a strawmANN-vs-Qdrant throughput comparison is licensed: the engines are at equal recall (§7.4). Conformance hash b8c6511753f0e22d.

On exact search the two engines' scores differ by at most 2.980e-07 (p99 1.192e-07), against the §8.4 floor absolute ε of 6.557e-07 — the expected summation error for this metric and dimension, used because no calibrated cell exists for them; the conformance calibrate command derives one from measured cross-ISA spread. §8.1: bit-exactness is unachievable between two different summation orders, so this — equal values within a measured tolerance — is the claim the speed rests on.

The conformance harness's single-client rate agrees on the ordering (2.01x to 2.05x); a different instrument, so no ratio is formed from it.

Every figure is the median of 3 passes per row per engine, alternated A/B/A/B (§7.4), and the spread is this run's own over 36 of 43 rows. The ingest and index-build rows (W0-upload, W1, W2, W6-upload, W7-upload, W8-upload, W12-upload) have none, so no build time carries a verdict. Each pass rebuilds the index, so the bands include build variance and are wider than a floor measured against one standing graph.

Units are queries per second. bfb reports rps, which counts batch requests: at --search-batch-size 16 the two differ by 16x, and reading one as the other once turned a 2.2x speedup into an apparent 7x regression. The tables show the request rate wherever it diverges.

The open-loop rows are not a speed. W4-sat50/70/90 offer a fixed fraction of measured saturation; serving it means the engine kept up, not that it was faster, so no ratio is printed. They exist because --parallel is a closed loop, where a stalled server stops receiving requests and understates its own tail.

ef is the same unit here: Qdrant held 2 segments for this run, one populated and 1 empty (read back per segment from the engine), and strawmANN held one graph, so equal ef is equal traversal width and the curves may be read at equal x. That is a property of this run, not of the engines.

What was measured builds, dataset, host

	strawmANN `sm-hnm-perf-0929`	Qdrant `qd-hnm-perf-0929`
engine	commit `e14920833a08` `ReleaseFast`, native build, vnni on binary sha256 `eeb45cddf8af63e5` built 2026-09-28T12:30:05Z with zig 0.16.0	version 1.19.2-dev binary `~/.cache/strawmann/qdrant-dbeb0f73/qdrant` sha256 `dbeb0f73dea2d371` build `878843e6` (from the server's banner, not a checkout) native binary outside a checkout: sha256 is the identity (§8.9) network `native` no container in the path, like strawmann
measured	2026-09-29T04:30:25Z to 2026-09-29T07:20:31Z (3 passes)	2026-09-29T05:05:58Z to 2026-09-29T07:55:51Z (3 passes)
profile	`as-deployed` · both engines
load generator	bfb dev @ fc6632e5 (qdrant/bfb#176; carries #172, findings 32's --rps reaping fix) · both engines
client	qdrant-client 1.16.1-dev (git dev branch) · both engines
launched as	`~/Workspace/strawmann/zig-out/bin/strawmann --port 6334 --capacity 131375 --connections 64 --workers 7 --io-threads 1 --pin --cpus 4-11 --data-dir ~/.cache/strawmann/strawmann-storage --default-placement cached`	`~/.cache/strawmann/qdrant-dbeb0f73/qdrant`
cores the engine could use	`4-11` (8 cores) requested by the harness `4-11` (8 cores) observed on 8 threads `0-23` (24 cores) observed on 1 thread	`4-11` (8 cores) requested by the harness `4-11` (8 cores) observed on 50 threads

Dataset

h-and-m-2048-angular-filters, 105100 × 2048, cosine, 10000 held-out queries

ground truth: shipped, and diffed against our fp64 recompute

1 file, each pinned by sha256 in datasets.json

Host §7.1 gate pass

AMD Ryzen AI 9 HX PRO 370 w/ Radeon 890M

24 logical cores · 58.6 GB · kernel 7.0.0-34-generic

memory bandwidth: 75.2 GB/s aggregate (24 threads) · 44.3 GB/s single core (59% of bus)

strawmann startup banner, 2026-09-29T04:30:25Z; the Qdrant run agrees within 10%

strawmANN run start: environment hash 373e8531fd3d1bf6

Qdrant run start: environment hash 373e8531fd3d1bf6

All throughput rows every measurement, with its notes

workload		strawmANN	Qdrant	ratio	notes
W0	d=4 floor: graph traversal with the distance taken out	4,866	4,047	1.20x	1.20x is 1.65x less work per query x 0.65x cores busy during the row (0.65 against 1.00) x 1.00x clock x 1.12x counted on-CPU share: the middle term is occupancy, not search speed d=4 floor: this measures graph traversal and heaps with the distance taken out, not request plumbing (findings 28: 76% of the server's CPU was HNSW search, 24% kernel; the RPC path is a small remainder)
W3	search, fp32, single query	1,281	986	1.30x
W4	search, saturating (closed loop)	4,656	5,683	0.82x
W4-sat50	search, fixed rate at 50% of saturation (open loop)	2,328	2,841	offered
W4-sat70	search, fixed rate at 70% of saturation (open loop)	3,259	3,978	offered
W4-sat90	search, fixed rate at 90% of saturation (open loop)	4,191	5,115	offered
W5	search batched (16 distinct dataset queries per request)	4,656291 requests/s	2,164136 requests/s	2.15x	per-batch latency (16 queries/request); queries: dataset, random-sample 2.15x is 0.59x less work per query x 3.60x cores busy during the row (7.10 against 1.97) x 1.00x clock x 1.01x counted on-CPU share: the middle term is occupancy, not search speed batched 16, so qps and rps differ by 16x; the ratio uses qps
W6	quantized: scalar	3,621	2,726	1.33x
W6-ef32	SQ8 recall control, ef=32 (latency only)	7,619	5,268	1.45x	1.45x is 1.76x less work per query x 0.78x cores busy during the row (1.55 against 2.00) x 1.00x clock x 1.06x counted on-CPU share: the middle term is occupancy, not search speed
W6-ef64	SQ8 recall control, ef=64 (latency only)	5,058	3,985	1.27x
W6-ef128	SQ8 recall control, ef=128 (latency only)	3,615	2,731	1.32x
W6-ef256	SQ8 recall control, ef=256 (latency only)	2,397	1,734	1.38x
W6-ef512	SQ8 recall control, ef=512 (latency only)	1,423	1,005	1.42x
W7	quantized: binary + oversampling	4,352	4,354	parity	within the ±2.6% band this dataset's noise floor puts on W7: no measured difference, not a small one
W8	quantized: PQ	1,452	1,121	1.30x
W9	exact / brute force	71	71	parity	within the ±3.1% band this dataset's noise floor puts on W9: no measured difference, not a small one brute force over the whole collection, no index involved
W10-ef32	recall control, ef=32 (latency only)	11,967	10,428	1.15x	1.15x is 0.92x less work per query x 1.21x cores busy during the row (6.96 against 5.77) x 1.00x clock x 1.04x counted on-CPU share: the middle term is occupancy, not search speed
W10-ef64	recall control, ef=64 (latency only)	7,476	7,141	1.05x
W10-ef128	recall control, ef=128 (latency only)	4,636	4,791	0.97x
W10-ef256	recall control, ef=256 (latency only)	2,852	3,120	0.91x
W10-ef512	recall control, ef=512 (latency only)	1,731	1,959	0.88x
W12-sel1	filtered search, one keyword (~1% of bench12)	2,594	2,503	parity	within the ±9.1% band this dataset's noise floor puts on W12-sel1: no measured difference, not a small one filtered search over a keyword payload index both engines were asked to build; whether each did is read back from the engine and refused beside the row when it did not. Recall is measured under the filter, against ground truth restricted to the matching set
W12-sel10	filtered search, any of 10 keywords (~10% of bench12)	1,147	1,280	parity	within the ±12.7% band this dataset's noise floor puts on W12-sel10: no measured difference, not a small one filtered search over a keyword payload index both engines were asked to build; whether each did is read back from the engine and refused beside the row when it did not. Recall is measured under the filter, against ground truth restricted to the matching set
W12-sel1-ef32	filtered recall control, one keyword, ef=32 (latency only)	2,605	4,599	0.57x
W12-sel1-ef64	filtered recall control, one keyword, ef=64 (latency only)	2,599	3,486	0.75x
W12-sel1-ef128	filtered recall control, one keyword, ef=128 (latency only)	2,612	2,510	parity	within the ±9.1% band this dataset's noise floor puts on W12-sel1-ef128: no measured difference, not a small one
W12-sel1-ef256	filtered recall control, one keyword, ef=256 (latency only)	2,593	1,742	1.49x
W12-sel1-ef512	filtered recall control, one keyword, ef=512 (latency only)	2,606	1,137	2.29x
W12-sel10-ef32	filtered recall control, any of 10 keywords, ef=32 (latency only)	2,583	2,998	-	recall unequal: 0.9929 vs 0.8703; §7.4 compares at equal recall
W12-sel10-ef64	filtered recall control, any of 10 keywords, ef=64 (latency only)	1,761	2,081	-	recall unequal: 0.9975 vs 0.9666; §7.4 compares at equal recall
W12-sel10-ef128	filtered recall control, any of 10 keywords, ef=128 (latency only)	1,146	1,268	parity	within the ±12.7% band this dataset's noise floor puts on W12-sel10-ef128: no measured difference, not a small one
W12-sel10-ef256	filtered recall control, any of 10 keywords, ef=256 (latency only)	408	784	0.52x
W12-sel10-ef512	filtered recall control, any of 10 keywords, ef=512 (latency only)	414	486	0.85x
W13	scroll / pagination	50,845	46,450	1.09x	strawmANN: -n 200000 (4x the table's 50000) Qdrant: -n 100000 (2x the table's 50000) strawmANN: 0.13 ms of the client's 0.14 ms p50 is not server time (13x), so 92% of this row is the load generator and the socket Qdrant: 0.13 ms of the client's 0.16 ms p50 is not server time (6x), so 82% of this row is the load generator and the socket 1.09x is 3.29x less work per query x 0.33x cores busy during the row (1.39 against 4.24) x 1.00x clock x 1.02x counted on-CPU share: the middle term is occupancy, not search speed
W11-steady	mixed read/write below the rebuild threshold: search bench2 while 5,255 synthetic points append	2,388	3,857	-	strawmANN: search covered 79% of the append; append 198 points/s Qdrant: search covered 49% of the append; append 198 points/s search-during-write; no recall join
W11	mixed read/write: search bench2 while 21,020 synthetic points append (runs last)	623	3,453	-	strawmANN: write overlap 88%; append 299 points/s Qdrant: search covered 21% of the append; append 299 points/s search-during-write; no recall join; the writer covered under 90% of strawmANN's search, so the last 12% of that row measured the rebuild the append provoked rather than a concurrent write

W10: throughput against ef

All latency rows closed loop included, p50 to max

A row flagged “… not server time” is one where the client saw far more than the server reported: below the rate at which a queue can form, what is left is the load generator's own scheduling.

workload		strawmANN p50	strawmANN p95	strawmANN p99	strawmANN p99.9	strawmANN max	Qdrant p50	Qdrant p95	Qdrant p99	Qdrant p99.9	Qdrant max
W0	d=4 floor: graph traversal with the distance taken out closed loop	201 µs	230 µs	249 µs	315 µs	1.41 ms	243 µs	275 µs	303 µs	374 µs	1.41 ms
W3	search, fp32, single query closed loop	759 µs	1.07 ms	1.40 ms	1.73 ms	4.02 ms	1.00 ms	1.32 ms	1.43 ms	1.54 ms	3.50 ms
W4	search, saturating (closed loop) closed loop	13.69 ms	14.80 ms	15.28 ms	34.24 ms	44.95 ms	10.97 ms	16.15 ms	22.55 ms	35.02 ms	54.93 ms
W4-sat50	search, fixed rate at 50% of saturation (open loop) open loop	889 µs	1.34 ms	1.57 ms	1.80 ms	5.50 ms	1.12 ms	1.54 ms	2.09 ms	2.49 ms	9.21 ms
W4-sat70	search, fixed rate at 70% of saturation (open loop) open loop	1.01 ms	1.80 ms	2.12 ms	2.47 ms	6.13 ms	1.30 ms	2.27 ms	2.65 ms	3.56 ms	10.24 ms
W4-sat90	search, fixed rate at 90% of saturation (open loop) open loop	1.15 ms	1.99 ms	2.57 ms	3.51 ms	7.14 ms	1.91 ms	4.45 ms	8.26 ms	13.36 ms	22.75 ms
W5	search batched (16 distinct dataset queries per request) closed loop	6.86 ms	7.77 ms	8.12 ms	8.55 ms	14.04 ms	14.78 ms	16.05 ms	16.64 ms	17.30 ms	18.72 ms
W6	quantized: scalar closed loop	543 µs	672 µs	842 µs	1.12 ms	1.67 ms	728 µs	876 µs	938 µs	1.03 ms	3.50 ms
W6-ef32	SQ8 recall control, ef=32 (latency only) closed loop	240 µs	387 µs	435 µs	509 µs	1.17 ms	375 µs	432 µs	464 µs	563 µs	3.71 ms
W6-ef64	SQ8 recall control, ef=64 (latency only) closed loop	377 µs	580 µs	700 µs	793 µs	1.39 ms	498 µs	580 µs	618 µs	716 µs	1.92 ms
W6-ef128	SQ8 recall control, ef=128 (latency only) closed loop	543 µs	674 µs	860 µs	1.14 ms	1.71 ms	726 µs	875 µs	936 µs	1.02 ms	3.77 ms
W6-ef256	SQ8 recall control, ef=256 (latency only) closed loop	826 µs	1.02 ms	1.10 ms	1.18 ms	2.28 ms	1.14 ms	1.42 ms	1.52 ms	1.63 ms	3.14 ms
W6-ef512	SQ8 recall control, ef=512 (latency only) closed loop	1.39 ms	1.74 ms	1.86 ms	2.01 ms	3.65 ms	1.98 ms	2.46 ms	2.63 ms	2.80 ms	4.63 ms
W7	quantized: binary + oversampling closed loop	433 µs	614 µs	677 µs	841 µs	1.25 ms	455 µs	503 µs	536 µs	651 µs	1.81 ms
W8	quantized: PQ closed loop	1.36 ms	1.74 ms	1.93 ms	2.28 ms	3.05 ms	1.76 ms	2.10 ms	2.26 ms	2.57 ms	3.91 ms
W9	exact / brute force closed loop	109.30 ms	147.44 ms	164.37 ms	180.92 ms	181.57 ms	113.19 ms	122.09 ms	128.73 ms	140.29 ms	146.54 ms
W10-ef32	recall control, ef=32 (latency only) closed loop	658 µs	866 µs	983 µs	1.22 ms	3.51 ms	714 µs	1.17 ms	1.39 ms	1.80 ms	3.92 ms
W10-ef64	recall control, ef=64 (latency only) closed loop	1.05 ms	1.45 ms	1.64 ms	1.87 ms	6.02 ms	1.03 ms	1.75 ms	2.06 ms	2.63 ms	6.11 ms
W10-ef128	recall control, ef=128 (latency only) closed loop	1.69 ms	2.43 ms	2.76 ms	3.19 ms	7.54 ms	1.56 ms	2.58 ms	3.01 ms	3.83 ms	7.27 ms
W10-ef256	recall control, ef=256 (latency only) closed loop	2.75 ms	4.06 ms	4.63 ms	5.37 ms	8.58 ms	2.46 ms	3.87 ms	4.57 ms	5.64 ms	9.31 ms
W10-ef512	recall control, ef=512 (latency only) closed loop	4.52 ms	6.79 ms	7.75 ms	8.93 ms	11.22 ms	3.99 ms	6.02 ms	7.07 ms	8.50 ms	11.40 ms
W12-sel1	filtered search, one keyword (~1% of bench12) closed loop	767 µs	819 µs	864 µs	930 µs	2.24 ms	797 µs	903 µs	949 µs	1.03 ms	2.83 ms
W12-sel10	filtered search, any of 10 keywords (~10% of bench12) closed loop	1.74 ms	2.29 ms	2.48 ms	2.68 ms	4.41 ms	1.57 ms	1.86 ms	1.96 ms	2.08 ms	4.21 ms
W12-sel1-ef32	filtered recall control, one keyword, ef=32 (latency only) closed loop	764 µs	815 µs	861 µs	970 µs	2.29 ms	433 µs	495 µs	529 µs	642 µs	1.75 ms
W12-sel1-ef64	filtered recall control, one keyword, ef=64 (latency only) closed loop	765 µs	817 µs	859 µs	934 µs	2.31 ms	574 µs	654 µs	692 µs	795 µs	2.13 ms
W12-sel1-ef128	filtered recall control, one keyword, ef=128 (latency only) closed loop	762 µs	810 µs	848 µs	939 µs	2.27 ms	795 µs	901 µs	944 µs	1.02 ms	2.67 ms
W12-sel1-ef256	filtered recall control, one keyword, ef=256 (latency only) closed loop	766 µs	820 µs	863 µs	936 µs	2.30 ms	1.14 ms	1.26 ms	1.32 ms	1.40 ms	3.35 ms
W12-sel1-ef512	filtered recall control, one keyword, ef=512 (latency only) closed loop	763 µs	815 µs	857 µs	936 µs	2.28 ms	1.76 ms	1.89 ms	1.95 ms	2.07 ms	4.18 ms
W12-sel10-ef32	filtered recall control, any of 10 keywords, ef=32 (latency only) closed loop	767 µs	972 µs	1.05 ms	1.24 ms	2.18 ms	661 µs	791 µs	862 µs	965 µs	2.34 ms
W12-sel10-ef64	filtered recall control, any of 10 keywords, ef=64 (latency only) closed loop	1.13 ms	1.47 ms	1.59 ms	1.75 ms	2.96 ms	963 µs	1.13 ms	1.20 ms	1.31 ms	3.70 ms
W12-sel10-ef128	filtered recall control, any of 10 keywords, ef=128 (latency only) closed loop	1.75 ms	2.29 ms	2.49 ms	2.70 ms	4.52 ms	1.59 ms	1.87 ms	1.97 ms	2.09 ms	4.85 ms
W12-sel10-ef256	filtered recall control, any of 10 keywords, ef=256 (latency only) closed loop	4.88 ms	5.36 ms	5.61 ms	5.90 ms	10.05 ms	2.59 ms	3.03 ms	3.18 ms	3.34 ms	5.95 ms
W12-sel10-ef512	filtered recall control, any of 10 keywords, ef=512 (latency only) closed loop	4.81 ms	5.18 ms	5.34 ms	5.67 ms	9.19 ms	4.17 ms	4.91 ms	5.16 ms	5.41 ms	8.57 ms
W13	scroll / pagination closed loop	138 µs	205 µs	232 µs	276 µs	1.08 ms	158 µs	223 µs	304 µs	466 µs	1.51 ms
W11-steady	mixed read/write below the rebuild threshold: search bench2 while 5,255 synthetic points append closed loop	3.10 ms	5.72 ms	6.75 ms	7.80 ms	9.31 ms	1.83 ms	3.54 ms	5.33 ms	16.33 ms	32.41 ms
W11	mixed read/write: search bench2 while 21,020 synthetic points append (runs last) closed loop	10.83 ms	23.04 ms	27.03 ms	31.01 ms	35.19 ms	2.07 ms	3.95 ms	6.82 ms	17.67 ms	31.98 ms

Storage and I/O block layer and syscalls, per row

The syscall rows count every descriptor, sockets included, so on a search row they measure the network rather than the disk.

	strawmANN	Qdrant
storage on disk	6.0 GiBbefore W11-steady, W11	4.6 GiBbefore W11-steady, W11
peak RSS	5.6 GiB	23.8 GiB8.6 GiB before the writers
of which anonymous	609.2 MiB	550.4 MiB
of which file-backed	5.0 GiB	7.1 GiB
disk read bytes	20.0 KiB	282.4 MiB
disk write bytes	5.0 GiB	53.9 GiB
disk read ops	15	8,733
disk write ops	82,932	903,863
syscall reads (all fds)	10,275,009	10,196
syscall writes (all fds)	4,599,952	11,471,461

measured via strawmANN: proc+cgroup / Qdrant: proc+cgroup. proc supplies syscall counts and block-layer bytes, cgroup supplies block-layer operations and bytes, so a row one interface does not carry reads n/a via …. unknown means it was not measured, and 0 means it was: an engine started with no --data-dir has no store, which is the row this section exists for. storage on disk is the level before the rows with a concurrent writer: during those an engine that rewrites segments is caught mid-rewrite, and the same row has read 3.47 and 10.11 GiB on two runs of one binary. peak RSS does include them, being a peak.

Per workload

A search row doing block-layer reads is an engine going to disk to answer a query.

workload	strawmANN read	strawmANN written	strawmANN read ops	strawmANN write ops	Qdrant read	Qdrant written	Qdrant read ops	Qdrant write ops
W0-upload	0	6.5 MiB	0	0	10.8 MiB	36.9 MiB	453	1,320
W0	0	0	0	105	0	0	0	0
W1	0	821.1 MiB	0	0	444.0 KiB	2.2 GiB	42	25,045
W2	0	821.1 MiB	0	26,502	12.0 MiB	3.7 GiB	456	63,640
W3	0	0	0	3	0	0	0	6
W4	0	0	0	0	0	0	0	0
W4-sat50	0	0	0	0	0	0	0	0
W4-sat70	0	0	0	0	0	0	0	0
W4-sat90	0	0	0	0	0	0	0	0
W5	0	0	0	0	0	0	0	0
W6-upload	0	821.1 MiB	0	13,246	14.2 MiB	4.6 GiB	501	78,766
W6	0	0	0	3	0	0	0	6
W6-ef32	0	0	0	0	0	0	0	0
W6-ef64	0	0	0	0	0	0	0	0
W6-ef128	0	0	0	0	0	0	0	0
W6-ef256	0	0	0	0	0	0	0	0
W6-ef512	0	0	0	0	0	0	0	0
W7-upload	0	821.1 MiB	0	13,243	15.5 MiB	4.5 GiB	588	76,196
W7	0	0	0	3	0	0	0	6
W8-upload	8.0 KiB	821.1 MiB	6	13,246	13.5 MiB	3.6 GiB	408	61,481
W8	0	0	0	3	0	0	0	0
W9	0	0	0	0	0	0	0	0
W10-ef32	0	0	0	0	0	0	0	0
W10-ef64	0	0	0	0	0	0	0	0
W10-ef128	0	0	0	0	0	0	0	0
W10-ef256	0	0	0	0	0	0	0	0
W10-ef512	0	0	0	0	0	0	0	0
W12-upload	12.0 KiB	821.1 MiB	9	13,243	24.6 MiB	3.7 GiB	807	64,840
W12-sel1	0	0	0	3	0	0	0	0
W12-sel10	0	0	0	0	0	0	0	0
W12-sel1-ef32	0	0	0	0	0	0	0	0
W12-sel1-ef64	0	0	0	0	0	0	0	0
W12-sel1-ef128	0	0	0	0	0	0	0	0
W12-sel1-ef256	0	0	0	0	0	0	0	0
W12-sel1-ef512	0	0	0	0	0	0	0	0
W12-sel10-ef32	0	0	0	0	0	0	0	0
W12-sel10-ef64	0	0	0	0	0	0	0	0
W12-sel10-ef128	0	0	0	0	0	0	0	0
W12-sel10-ef256	0	0	0	0	0	0	0	0
W12-sel10-ef512	0	0	0	0	0	0	0	0
W13	0	0	0	0	0	0	0	0
W11-steady	0	41.2 MiB	0	0	38.3 MiB	5.9 GiB	1,089	100,674
W11	0	164.5 MiB	0	3,332	152.9 MiB	25.7 GiB	4,389	431,883

Scheduler and memory CPU use, run-queue wait, migrations

Whether the engine was running while it ran. of wall is CPU over elapsed, waiting is runnable-but-not-scheduled, migrations checks the pinning claim, and switches gives voluntary over involuntary — the scheduler taking the core away against the engine choosing to sleep, which per unit of work is the cheapest signal of lock contention there is. A dash is not a zero: an index build's threads exit before the row does, and threads shows what fraction of the row the survivors account for.

Time spent waiting for a core

Lower is better; the bar between a pair is the gap.

Peak memory per row

Peak RSS while the row ran, from the engine's own process. Unlike the disk counters this is not refused across the two engines: residency decides where bytes live, and this is what the process held either way.

workload	strawmANN							Qdrant
workload	cpu	of wall	waiting	switches vol/invol	migrations	faults min/maj	threads	cpu	of wall	waiting	switches vol/invol	migrations	faults min/maj	threads
W0-upload	9.0 s	146%	4.2 ms	4,553 / 36	0	13,130 / 0	9 2%	12.4 s	187%	1,180.2 ms	17,205 / 2,032	1,910	49,093 / 127,992	42 14%
W0	7.1 s	68%	4.4 ms	164,008 / 11	0	0 / 0	9	12.6 s	102%	3.7 ms	560,500 / 16	149	282 / 0	37 0%
W1	2.0 s	64%	1.0 ms	97,353 / 3	0	225,897 / 0	9	18.2 s	390%	7,564.6 ms	19,232 / 5,768	4,367	160,649 / 251,721	54 72%
W2	167.8 s	639%	99.0 ms	98,924 / 830	0	229,765 / 0	9 1%	144.6 s	529%	7,150.1 ms	25,230 / 6,453	5,343	261,652 / 321,681	43 7%
W3	35.6 s	91%	3.3 ms	191,148 / 54	0	5 / 0	9	51.7 s	102%	4.9 ms	564,991 / 115	174	1,802 / 0	39 0%
W4	77.3 s	718%	7.7 ms	82,992 / 104	0	84 / 0	9	69.6 s	788%	67,279.5 ms	42,137 / 37,593	7,023	5,372 / 0	76
W4-sat50	167.8 s	195%	24.3 ms	489,583 / 116	0	12 / 0	9	224.8 s	319%	22,057.5 ms	1,696,973 / 13,810	497,175	3,260 / 0	68 0%
W4-sat70	196.9 s	320%	26.2 ms	446,669 / 135	0	20 / 0	9	244.4 s	485%	93,503.0 ms	1,383,575 / 77,473	583,329	2,241 / 0	68
W4-sat90	222.4 s	465%	29.4 ms	401,908 / 171	0	48 / 0	9	259.1 s	660%	161,417.8 ms	713,168 / 147,070	267,514	2,445 / 0	44 0%
W5	76.3 s	710%	7.2 ms	6,624 / 145	0	0 / 0	9	45.7 s	198%	9.6 ms	38,060 / 338	1,280	1,284 / 0	42 0%
W6-upload	227.9 s	258%	107.3 ms	29,404 / 1,377	3	716,129 / 0	9 1%	85.1 s	354%	3,386.9 ms	30,152 / 3,213	3,619	432,188 / 355,587	42 0%
W6	24.1 s	174%	6.3 ms	184,979 / 41	0	0 / 0	9	37.2 s	203%	10.9 ms	530,264 / 111	14,687	985 / 0	44 0%
W6-ef32	10.2 s	155%	2.2 ms	166,239 / 6	0	0 / 0	9	19.2 s	202%	8.5 ms	493,652 / 38	9,455	122 / 0	44
W6-ef64	16.3 s	164%	3.8 ms	180,002 / 11	0	0 / 0	9	25.5 s	203%	9.1 ms	513,176 / 42	11,474	129 / 0	44
W6-ef128	24.2 s	175%	2.9 ms	184,479 / 18	0	0 / 0	9	37.3 s	203%	10.8 ms	530,140 / 112	14,753	476 / 0	44
W6-ef256	38.2 s	183%	4.2 ms	183,644 / 25	0	0 / 0	9	58.5 s	202%	12.9 ms	541,209 / 209	18,679	640 / 0	44
W6-ef512	66.7 s	190%	6.3 ms	186,701 / 103	0	4 / 0	9	100.7 s	202%	71.4 ms	548,977 / 438	20,776	1,376 / 0	44
W7-upload	167.5 s	592%	502.4 ms	26,300 / 977	5	237,989 / 0	9 1%	37.8 s	235%	2,105.4 ms	30,544 / 1,808	3,933	328,498 / 413,120	42 0%
W7	19.5 s	169%	5.8 ms	183,976 / 33	0	0 / 0	9	23.1 s	201%	12.1 ms	486,770 / 35	8,960	506 / 0	46 0%
W8-upload	1,362.4 s	771%	433.9 ms	31,987 / 6,438	1	461,956 / 0	9 0%	955.9 s	636%	2,287.5 ms	329,850 / 14,650	15,664	252,009 / 287,843	42 0%
W8	65.3 s	189%	4.9 ms	189,322 / 81	0	0 / 0	9	89.9 s	202%	136.5 ms	520,095 / 469	20,325	5,327 / 0	46
W9	197.4 s	702%	28.8 ms	4,607 / 405	0	0 / 0	9	221.5 s	788%	11,013.9 ms	20,079 / 11,855	8,603	787 / 0	48
W10-ef32	28.9 s	686%	4.6 ms	96,554 / 42	0	0 / 0	9	27.9 s	576%	10,904.3 ms	241,833 / 21,485	72,162	1,315 / 0	48
W10-ef64	47.1 s	701%	5.6 ms	100,740 / 59	0	0 / 0	9	43.5 s	617%	28,791.1 ms	290,429 / 38,056	129,916	973 / 0	70
W10-ef128	76.5 s	707%	9.1 ms	104,056 / 112	0	4 / 0	9	66.2 s	632%	41,856.1 ms	313,068 / 41,854	150,106	577 / 0	63 0%
W10-ef256	124.4 s	708%	13.4 ms	108,762 / 213	0	4 / 0	9	105.4 s	656%	58,014.1 ms	333,899 / 55,939	178,287	724 / 0	65
W10-ef512	204.1 s	706%	22.7 ms	112,878 / 379	0	0 / 0	9	174.0 s	681%	80,763.0 ms	363,425 / 80,921	197,452	1,495 / 0	65
W12-upload	166.8 s	634%	94.9 ms	21,802 / 812	1	230,557 / 0	9 1%	219.2 s	436%	7,688.9 ms	37,271 / 8,846	4,185	214,691 / 352,826	50 0%
W12-sel1	34.8 s	180%	3.0 ms	160,548 / 67	0	0 / 0	9	40.6 s	203%	10.9 ms	529,296 / 113	13,621	673 / 0	55
W12-sel10	83.3 s	191%	4.9 ms	186,419 / 121	0	0 / 0	9	79.1 s	202%	48.9 ms	545,876 / 357	20,685	712 / 0	55
W12-sel1-ef32	34.7 s	180%	3.2 ms	159,742 / 19	0	0 / 0	9	22.1 s	202%	8.8 ms	503,380 / 62	10,523	204 / 0	55
W12-sel1-ef64	34.7 s	180%	5.1 ms	159,303 / 37	0	0 / 0	9	29.2 s	203%	12.2 ms	516,391 / 94	12,016	289 / 0	55
W12-sel1-ef128	34.6 s	180%	2.1 ms	161,430 / 41	0	0 / 0	9	40.4 s	203%	13.2 ms	528,221 / 150	14,175	292 / 0	55
W12-sel1-ef256	34.7 s	179%	1.9 ms	159,960 / 34	0	0 / 0	9	58.1 s	202%	20.9 ms	529,766 / 229	14,920	593 / 0	55
W12-sel1-ef512	34.6 s	180%	5.1 ms	161,106 / 22	0	0 / 0	9	88.2 s	200%	117.3 ms	511,258 / 490	13,954	942 / 0	55
W12-sel10-ef32	35.2 s	182%	9.3 ms	183,179 / 35	0	0 / 0	9	33.8 s	202%	10.3 ms	524,793 / 134	14,208	538 / 0	55
W12-sel10-ef64	53.1 s	187%	3.9 ms	183,905 / 55	0	0 / 0	9	48.7 s	202%	16.8 ms	534,062 / 192	16,801	266 / 0	55
W12-sel10-ef128	83.5 s	191%	5.6 ms	186,655 / 157	0	0 / 0	9	79.8 s	202%	62.9 ms	544,704 / 357	20,657	940 / 0	55
W12-sel10-ef256	231.5 s	189%	31.8 ms	115,826 / 944	0	0 / 0	9	128.6 s	202%	76.6 ms	554,834 / 465	19,993	1,458 / 0	55
W12-sel10-ef512	231.3 s	192%	35.0 ms	113,692 / 888	0	0 / 0	9	204.8 s	199%	87.0 ms	571,091 / 1,566	22,174	2,574 / 0	55
W13	5.6 s	137%	2.4 ms	243,523 / 11	0	0 / 0	9	9.2 s	414%	932.5 ms	381,150 / 4,571	112,908	425 / 0	68
W11-steady	147.1 s	701%	20.7 ms	105,734 / 297	0	12,338 / 0	9	96.9 s	745%	77,335.9 ms	349,636 / 75,751	171,847	403,201 / 130,786	46 22%
W11	606.7 s	756%	309,613.4 ms	110,900 / 57,271	71	58,385 / 0	9 87%	156.9 s	1,081%	100,964.5 ms	407,895 / 96,883	182,017	1,670,641 / 591,145	54 35%

Waiting and stalls where the time went when the engine was not running

waiting is runnable and not scheduled, blocked on disk is not runnable at all, and pressure is PSI for the engine's cgroup (some = at least one task stalled, full = every runnable task).

Time stalled on I/O

Time every task in the engine's cgroup was stalled on I/O. Lower is better. 34 rows never stalled on I/O and are not drawn.

workload	strawmANN					Qdrant
workload	waiting	blocked on disk	cpu some/full	io some/full	memory some/full	waiting	blocked on disk	cpu some/full	io some/full	memory some/full
W0-upload	4.2 ms	0 ms	2 / 2 ms	0 / 0 ms	0 / 0 ms	1,180.2 ms	0 ms	118 / 3 ms	13 / 13 ms	0 / 0 ms
W0	4.4 ms	0 ms	49 / 49 ms	0 / 0 ms	0 / 0 ms	3.7 ms	0 ms	70 / 70 ms	0 / 0 ms	0 / 0 ms
W1	1.0 ms	0 ms	8 / 8 ms	2 / 2 ms	0 / 0 ms	7,564.6 ms	0 ms	734 / 5 ms	57 / 29 ms	0 / 0 ms
W2	99.0 ms	0 ms	20 / 11 ms	1 / 1 ms	0 / 0 ms	7,150.1 ms	0 ms	664 / 10 ms	149 / 105 ms	0 / 0 ms
W3	3.3 ms	0 ms	42 / 42 ms	0 / 0 ms	0 / 0 ms	4.9 ms	0 ms	97 / 97 ms	0 / 0 ms	0 / 0 ms
W4	7.7 ms	0 ms	4 / 4 ms	0 / 0 ms	0 / 0 ms	67,279.5 ms	0 ms	3,490 / 2 ms	0 / 0 ms	0 / 0 ms
W4-sat50	24.3 ms	0 ms	160 / 160 ms	0 / 0 ms	0 / 0 ms	22,057.5 ms	0 ms	2,623 / 219 ms	0 / 0 ms	0 / 0 ms
W4-sat70	26.2 ms	0 ms	148 / 148 ms	0 / 0 ms	0 / 0 ms	93,503.0 ms	0 ms	9,318 / 146 ms	0 / 0 ms	0 / 0 ms
W4-sat90	29.4 ms	0 ms	117 / 117 ms	0 / 0 ms	0 / 0 ms	161,417.8 ms	0 ms	12,693 / 71 ms	0 / 0 ms	0 / 0 ms
W5	7.2 ms	0 ms	3 / 3 ms	0 / 0 ms	0 / 0 ms	9.6 ms	0 ms	15 / 15 ms	0 / 0 ms	0 / 0 ms
W6-upload	107.3 ms	0 ms	33 / 20 ms	0 / 0 ms	0 / 0 ms	3,386.9 ms	0 ms	331 / 13 ms	359 / 349 ms	0 / 0 ms
W6	6.3 ms	0 ms	40 / 40 ms	0 / 0 ms	0 / 0 ms	10.9 ms	0 ms	63 / 62 ms	0 / 0 ms	0 / 0 ms
W6-ef32	2.2 ms	0 ms	24 / 24 ms	0 / 0 ms	0 / 0 ms	8.5 ms	0 ms	52 / 52 ms	0 / 0 ms	0 / 0 ms
W6-ef64	3.8 ms	0 ms	39 / 39 ms	0 / 0 ms	0 / 0 ms	9.1 ms	0 ms	57 / 56 ms	0 / 0 ms	0 / 0 ms
W6-ef128	2.9 ms	0 ms	40 / 40 ms	0 / 0 ms	0 / 0 ms	10.8 ms	0 ms	63 / 62 ms	0 / 0 ms	0 / 0 ms
W6-ef256	4.2 ms	0 ms	38 / 38 ms	0 / 0 ms	0 / 0 ms	12.9 ms	0 ms	75 / 74 ms	0 / 0 ms	0 / 0 ms
W6-ef512	6.3 ms	0 ms	39 / 39 ms	0 / 0 ms	0 / 0 ms	71.4 ms	0 ms	136 / 128 ms	0 / 0 ms	0 / 0 ms
W7-upload	502.4 ms	0 ms	69 / 6 ms	8 / 8 ms	0 / 0 ms	2,105.4 ms	0 ms	271 / 11 ms	198 / 173 ms	0 / 0 ms
W7	5.8 ms	0 ms	34 / 34 ms	0 / 0 ms	0 / 0 ms	12.1 ms	0 ms	55 / 54 ms	0 / 0 ms	0 / 0 ms
W8-upload	433.9 ms	0 ms	57 / 11 ms	3 / 3 ms	0 / 0 ms	2,287.5 ms	0 ms	917 / 120 ms	256 / 153 ms	0 / 0 ms
W8	4.9 ms	0 ms	37 / 37 ms	0 / 0 ms	0 / 0 ms	136.5 ms	0 ms	122 / 106 ms	0 / 0 ms	0 / 0 ms
W9	28.8 ms	0 ms	4 / 4 ms	0 / 0 ms	0 / 0 ms	11,013.9 ms	0 ms	1,259 / 21 ms	0 / 0 ms	0 / 0 ms
W10-ef32	4.6 ms	0 ms	12 / 12 ms	0 / 0 ms	0 / 0 ms	10,904.3 ms	0 ms	1,266 / 21 ms	0 / 0 ms	0 / 0 ms
W10-ef64	5.6 ms	0 ms	11 / 11 ms	0 / 0 ms	0 / 0 ms	28,791.1 ms	0 ms	2,667 / 24 ms	0 / 0 ms	0 / 0 ms
W10-ef128	9.1 ms	0 ms	10 / 10 ms	0 / 0 ms	0 / 0 ms	41,856.1 ms	0 ms	3,867 / 26 ms	0 / 0 ms	0 / 0 ms
W10-ef256	13.4 ms	0 ms	9 / 9 ms	0 / 0 ms	0 / 0 ms	58,014.1 ms	0 ms	5,612 / 35 ms	0 / 0 ms	0 / 0 ms
W10-ef512	22.7 ms	0 ms	9 / 9 ms	0 / 0 ms	0 / 0 ms	80,763.0 ms	0 ms	8,206 / 39 ms	0 / 0 ms	0 / 0 ms
W12-upload	94.9 ms	0 ms	15 / 6 ms	10 / 10 ms	0 / 0 ms	7,688.9 ms	0 ms	758 / 18 ms	148 / 101 ms	0 / 0 ms
W12-sel1	3.0 ms	0 ms	38 / 38 ms	0 / 0 ms	0 / 0 ms	10.9 ms	0 ms	64 / 63 ms	0 / 0 ms	0 / 0 ms
W12-sel10	4.9 ms	0 ms	37 / 37 ms	0 / 0 ms	0 / 0 ms	48.9 ms	0 ms	112 / 107 ms	0 / 0 ms	0 / 0 ms
W12-sel1-ef32	3.2 ms	0 ms	38 / 38 ms	0 / 0 ms	0 / 0 ms	8.8 ms	0 ms	54 / 54 ms	0 / 0 ms	0 / 0 ms
W12-sel1-ef64	5.1 ms	0 ms	37 / 37 ms	0 / 0 ms	0 / 0 ms	12.2 ms	0 ms	59 / 58 ms	0 / 0 ms	0 / 0 ms
W12-sel1-ef128	2.1 ms	0 ms	38 / 38 ms	0 / 0 ms	0 / 0 ms	13.2 ms	0 ms	64 / 63 ms	0 / 0 ms	0 / 0 ms
W12-sel1-ef256	1.9 ms	0 ms	38 / 38 ms	0 / 0 ms	0 / 0 ms	20.9 ms	0 ms	72 / 71 ms	0 / 0 ms	0 / 0 ms
W12-sel1-ef512	5.1 ms	0 ms	37 / 37 ms	0 / 0 ms	0 / 0 ms	117.3 ms	0 ms	108 / 94 ms	0 / 0 ms	0 / 0 ms
W12-sel10-ef32	9.3 ms	0 ms	36 / 36 ms	0 / 0 ms	0 / 0 ms	10.3 ms	0 ms	61 / 61 ms	0 / 0 ms	0 / 0 ms
W12-sel10-ef64	3.9 ms	0 ms	37 / 37 ms	0 / 0 ms	0 / 0 ms	16.8 ms	0 ms	68 / 67 ms	0 / 0 ms	0 / 0 ms
W12-sel10-ef128	5.6 ms	0 ms	37 / 37 ms	0 / 0 ms	0 / 0 ms	62.9 ms	0 ms	114 / 108 ms	0 / 0 ms	0 / 0 ms
W12-sel10-ef256	31.8 ms	0 ms	42 / 42 ms	0 / 0 ms	0 / 0 ms	76.6 ms	0 ms	144 / 139 ms	0 / 0 ms	0 / 0 ms
W12-sel10-ef512	35.0 ms	0 ms	42 / 42 ms	0 / 0 ms	0 / 0 ms	87.0 ms	0 ms	162 / 156 ms	0 / 0 ms	0 / 0 ms
W13	2.4 ms	0 ms	28 / 28 ms	0 / 0 ms	0 / 0 ms	932.5 ms	0 ms	130 / 26 ms	0 / 0 ms	0 / 0 ms
W11-steady	20.7 ms	0 ms	15 / 15 ms	0 / 0 ms	0 / 0 ms	77,335.9 ms	0 ms	5,714 / 49 ms	344 / 323 ms	0 / 0 ms
W11	309,613.4 ms	0 ms	38,673 / 19 ms	10 / 6 ms	0 / 0 ms	100,964.5 ms	0 ms	6,956 / 71 ms	2,067 / 2,014 ms	0 / 0 ms

A dash under blocked on disk is not a zero: most hosts ship with kernel.task_delayacct=0, which reports the field as a permanent zero and would manufacture the strongest claim here — that the memory-resident engine never waits for a device — out of a sysctl. bench/setup.py apply turns it on.

Hardware counters cycles, DRAM loads, TLB walks, IPC per query

What the core did per query, from perf stat attached to the engine for the same window as the /proc counters. §5's cost model is a set of claims about instructions per cycle, DRAM traffic and TLB reach; these are those quantities, measured on the row the headline quotes rather than on a microbenchmark.

What one query cost, in cycles

Lower is better; the bar between a pair is the gap. Load rows are absent: they have no queries to divide by, and an absolute count under a per-query axis would be a different quantity wearing this one's label.

Demand loads from DRAM per query

Demand loads served from DRAM, times the cache line this host reports. Lower is better. Demand only: the hardware prefetcher's fills are a separate counter and are not in this number, so a row that streams — an exact scan above all — moved far more than this says. On the graph rows, where there is little for a prefetcher to predict, it is most of the traffic and is the outstanding-miss quantity §5.2 argues the engine is limited by.

TLB walks per query

Data TLB misses that reached a page walk, per query. Lower is better. §5.5 argues a memory-resident index needs hugepage care; this is what not taking it costs, and `--no-huge-pages` is the A/B arm that prices it.

Instructions per cycle

How well the core was fed while it ran. Not a score: a low IPC on a memory-bound row is what §5.2 predicts, and a high one on a row that does more work per query is not a win. Read it beside the two charts above.

Branch mispredictions per 1k instructions

A graph traversal is a chain of data-dependent branches and none of them is predictable from the last query, so this is the column that separates a slow kernel from an unpredictable walk. Per thousand instructions rather than per branch: `branches` costs a PMU counter that `ref-cycles` needs more, and MPKI is the comparable form anyway.

workload	strawmANN						Qdrant
workload	IPC	GHz	branch MPKI	cycles/query	demand DRAM/query	TLB walks/query	IPC	GHz	branch MPKI	cycles/query	demand DRAM/query	TLB walks/query
W0-upload	1.93	2.001.004x nominal	5.40	-	-	-	1.84	2.011.005x nominal	4.53	-	-	-
W0	1.34	2.011.005x nominal	6.05	229,551	4.4 KiB	633.9	1.41	2.011.004x nominal	3.12	378,757	7.1 KiB	699.8
W1	1.82	2.011.005x nominal	0.61	-	-	-	1.69	2.001.003x nominal	0.89	-	-	-
W2	0.42	2.011.005x nominal	2.37	-	-	-	0.73	2.011.005x nominal	1.72	-	-	-
W3	0.69	2.011.005x nominal	4.01	1,343,806	3,937.2 KiB	2,447.6	0.82	2.011.006x nominal	2.22	1,926,185	2,248.8 KiB	4,407.3
W4	0.30	2.011.006x nominal	3.26	3,086,300	2,809.6 KiB	2,346.1	0.53	2.011.006x nominal	2.32	2,743,463	2,112.1 KiB	3,603.8
W4-sat50	0.57	2.011.005x nominal	4.05	1,625,484	3,554.2 KiB	2,363.9	0.74	2.011.006x nominal	2.52	2,107,255	2,263.7 KiB	4,316.8
W4-sat70	0.47	2.011.006x nominal	3.92	1,951,256	3,262.1 KiB	2,338.4	0.68	2.011.005x nominal	2.57	2,302,937	2,224.5 KiB	4,170.7
W4-sat90	0.42	2.011.005x nominal	3.67	2,199,343	2,925.4 KiB	2,311.1	0.60	2.011.006x nominal	2.54	2,504,920	2,119.5 KiB	3,894.9
W5	0.28	2.011.005x nominal	3.44	3,053,357	2,801.5 KiB	2,285.4	0.72	2.011.006x nominal	2.55	1,813,718	2,334.2 KiB	3,468.9
W6-upload	0.59	2.011.005x nominal	12.01	-	-	-	1.90	2.011.005x nominal	1.59	-	-	-
W6	0.92	2.011.005x nominal	4.81	897,668	2,476.9 KiB	2,729.6	1.51	2.011.006x nominal	1.90	1,368,830	681.3 KiB	2,990.0
W6-ef32	1.01	2.011.006x nominal	2.53	373,764	748.2 KiB	1,162.1	1.68	2.011.006x nominal	1.41	656,743	231.2 KiB	1,449.4
W6-ef64	0.90	2.011.005x nominal	4.16	589,833	1,411.1 KiB	1,769.8	1.61	2.011.006x nominal	1.63	903,927	387.5 KiB	2,013.4
W6-ef128	0.92	2.011.005x nominal	4.79	899,695	2,475.3 KiB	2,729.1	1.51	2.011.006x nominal	1.90	1,366,164	680.2 KiB	2,990.1
W6-ef256	0.94	2.011.005x nominal	5.29	1,463,001	4,321.8 KiB	4,436.5	1.42	2.011.006x nominal	2.16	2,206,742	1,230.5 KiB	4,592.3
W6-ef512	0.93	2.011.006x nominal	5.63	2,603,840	7,520.3 KiB	7,889.9	1.32	2.011.006x nominal	2.59	3,825,554	2,295.7 KiB	7,272.7
W7-upload	0.42	2.011.005x nominal	2.94	-	-	-	2.03	2.011.005x nominal	4.55	-	-	-
W7	0.85	2.011.006x nominal	9.15	724,084	726.7 KiB	1,811.3	1.46	2.011.005x nominal	3.60	811,466	306.7 KiB	2,155.0
W8-upload	6.26	2.001.004x nominal	0.48	-	-	-	5.57	2.011.004x nominal	0.16	-	-	-
W8	3.94	2.011.006x nominal	0.50	2,546,739	620.5 KiB	2,848.2	3.20	2.011.006x nominal	0.55	3,437,700	429.7 KiB	3,954.5
W9	0.24	2.001.004x nominal	0.23	197,681,596	236,938.1 KiB	65,509.7	0.36	2.011.006x nominal	0.14	221,203,346	82,785.0 KiB	212,349.5
W10-ef32	0.36	2.011.006x nominal	2.23	1,139,494	981.0 KiB	815.4	0.78	2.011.006x nominal	2.06	1,047,142	846.8 KiB	1,682.6
W10-ef64	0.32	2.011.006x nominal	2.81	1,869,669	1,680.8 KiB	1,347.0	0.68	2.011.006x nominal	2.35	1,627,943	1,340.7 KiB	2,553.9
W10-ef128	0.30	2.011.006x nominal	3.30	3,046,492	2,840.4 KiB	2,342.9	0.63	2.011.006x nominal	2.57	2,508,009	2,155.5 KiB	3,954.2
W10-ef256	0.30	2.011.006x nominal	3.79	4,961,613	4,791.7 KiB	4,257.1	0.58	2.011.006x nominal	2.82	4,045,342	3,435.1 KiB	6,208.7
W10-ef512	0.31	2.011.006x nominal	4.11	8,166,390	8,023.1 KiB	8,115.6	0.55	2.011.006x nominal	2.96	6,760,967	5,728.7 KiB	9,967.1
W12-upload	0.42	2.011.006x nominal	2.40	-	-	-	0.86	2.001.004x nominal	1.82	-	-	-
W12-sel1	0.50	2.011.006x nominal	2.67	1,328,617	4,467.9 KiB	2,131.3	1.00	2.011.006x nominal	3.44	1,497,889	1,218.6 KiB	2,347.9
W12-sel10	1.10	2.011.006x nominal	4.13	3,277,445	4,930.4 KiB	6,298.6	0.94	2.011.006x nominal	2.61	2,993,718	2,705.6 KiB	3,681.8
W12-sel1-ef32	0.50	2.011.006x nominal	2.65	1,326,974	4,470.3 KiB	2,130.7	1.11	2.011.006x nominal	2.33	767,892	563.2 KiB	1,488.3
W12-sel1-ef64	0.50	2.011.006x nominal	2.69	1,329,005	4,470.3 KiB	2,133.0	1.04	2.011.006x nominal	2.87	1,047,413	826.2 KiB	1,878.0
W12-sel1-ef128	0.50	2.011.006x nominal	2.66	1,322,826	4,466.8 KiB	2,130.8	1.00	2.011.006x nominal	3.45	1,494,591	1,214.2 KiB	2,349.7
W12-sel1-ef256	0.50	2.011.006x nominal	2.66	1,329,294	4,474.8 KiB	2,133.0	1.00	2.011.005x nominal	4.09	2,193,453	1,726.2 KiB	2,898.7
W12-sel1-ef512	0.50	2.011.006x nominal	2.65	1,325,470	4,466.1 KiB	2,129.5	0.99	2.011.006x nominal	4.93	3,384,916	2,425.0 KiB	3,411.3
W12-sel10-ef32	1.04	2.011.006x nominal	3.54	1,343,106	2,070.9 KiB	2,512.7	1.05	2.011.006x nominal	1.97	1,232,843	1,007.6 KiB	2,000.8
W12-sel10-ef64	1.06	2.011.005x nominal	3.89	2,060,532	3,204.8 KiB	3,854.6	1.01	2.011.006x nominal	2.13	1,822,159	1,610.2 KiB	2,669.4
W12-sel10-ef128	1.10	2.011.005x nominal	4.14	3,281,930	4,932.2 KiB	6,303.5	0.93	2.011.006x nominal	2.64	3,018,862	2,734.5 KiB	3,682.8
W12-sel10-ef256	0.55	2.011.006x nominal	0.73	9,224,485	26,914.0 KiB	15,346.9	0.92	2.011.005x nominal	2.91	4,936,601	4,436.2 KiB	5,116.2
W12-sel10-ef512	0.55	2.011.006x nominal	0.79	9,207,190	27,014.5 KiB	15,339.9	0.94	2.011.005x nominal	3.02	7,972,865	6,902.6 KiB	7,207.1
W13	1.36	2.011.007x nominal	1.20	42,457	1.0 KiB	12.9	1.45	2.011.006x nominal	1.46	139,544	1.4 KiB	37.1
W11-steady	0.33	2.011.005x nominal	1.75	5,868,526	5,842.3 KiB	3,195.9	0.79	2.001.004x nominal	1.86	3,660,394	2,818.8 KiB	4,559.9
W11	0.26	2.011.005x nominal	1.09	24,190,691	28,713.5 KiB	9,694.3	1.06	2.011.005x nominal	1.28	6,049,858	4,563.7 KiB	6,796.6

Nothing here is scaled. Where perf had to multiplex the group, the values it prints are extrapolations from the fraction of the row each counter was on, and they are withheld rather than shown — the same rule the scheduler table applies to a thread that exited. An event this host does not implement is likewise blank, never zero.

The two instruments disagree on these rows. Qdrant: perf and /proc disagree on minor faults by up to 48% on W0-upload, W2, W6-upload, W7-upload, W8-upload, W12-upload, W11-steady, W11; Qdrant: perf and /proc disagree on context switches by up to 75% on W0-upload, W1, W6-upload, W7-upload, W8-upload, W12-upload. perf keeps an exiting thread's counts and the /proc sums do not, so a gap here is usually the same lost-thread effect the scheduler table reports as coverage.

Collection config what each engine says it built

Read back from the engine rather than taken from the request. --segments 1 sets Qdrant's default_segment_number, which its optimizer treats as a target, and the segment count is the largest confound in the ef comparison. strawmANN held 1 segment; Qdrant held 2 segments.

Where the engines disagree a cell reads strawmANN / Qdrant, and is marked.

collection	segments	populated segments	requested segments	points	indexed vectors	vector size	hnsw m	hnsw ef_construct	quantization	shards	vector residency
bench0	1 / 2	- / 1	- / 1	105,100	105,100	4	16	100	-	1	cached
bench1	1 / 6	- / 6	- / 1	105,100 / 103,400	0 / 12,700	2,048	16	100	-	1	cached
bench2	1 / 2	- / 1	- / 1	105,100	105,100	2,048	16	100	-	1	cached
bench6	1 / 2	- / 1	- / 1	105,100	105,100	2,048	16	100	scalar	1	cached
bench7	1 / 2	- / 1	- / 1	105,100	105,100	2,048	16	100	binary	1	cached
bench8	1 / 2	- / 1	- / 1	105,100	105,100	2,048	16	100	product	1	cached
bench12	1 / 2	- / 1	- / 1	105,100	105,100	2,048	16	100	-	1	cached

After the mutating rows bench2 held strawmANN 131,375 (+26,275), 127,843 of them indexed; Qdrant 131,375 (+26,275), 131,375 of them indexed. The table above is the state the throughput, latency and recall rows searched; this is what W11 left, and is that row's subject rather than theirs.

bench1 was read back straight after its row and dropped, with no settle between, so an engine still building it reports a snapshot taken mid-ingest. Its cells are not marked as a disagreement.

Per workload every metric of every row, engine beside engine

Metric down, engine across, so a comparison is two adjacent cells. Metrics a row did not measure are dropped rather than shown empty.

W0-upload transport floor: load

upload · collection=bench0 · client -p 2 -t 2 -c 1 (-p, -t, -c bfb default) · n=105,100

metric	strawmANN	Qdrant
wall clock	6.2 s	6.7 s	1.08x
of which upload	0.1 s	0.6 s	4.53x
of which index wait	4.0 s	4.0 s	~equal
time to Green	4.0 s	4.0 s (at bfb's polling floor)	~equal
cpu	9.0 s	12.4 s	1.38x
cpu, % of wall	146%	187%
waiting for a core	4.2 ms	1,180.2 ms	279.04x
migrations	0	1,910
faults min/maj	13,130 / 0	49,093 / 127,992
peak RSS	144.7 MiB	761.8 MiB	5.27x
disk written	6.5 MiB	36.9 MiB
disk read	0	10.8 MiB

W0 d=4 floor: graph traversal with the distance taken out 1.20x

closed-loop · collection=bench0 · client -p 1 -t 2 -c 1 (-t, -c bfb default) · n=50,000

metric	strawmANN	Qdrant
queries/second	4,866	4,047	1.20x
client p50	201 µs	243 µs	1.21x
client p99	249 µs	303 µs	1.22x
client p99.9	315 µs	374 µs	1.19x
server p50	110 µs	135 µs	1.24x
server p99	121 µs	172 µs	1.42x
wall clock	10.3 s	12.4 s	1.20x
queries sent	50,000	50,000
cpu	7.1 s	12.6 s	1.79x
cpu, % of wall	68%	102%
waiting for a core	4.4 ms	3.7 ms	0.85x
migrations	0	149
faults min/maj	0 / 0	282 / 0
peak RSS	144.7 MiB	760.9 MiB	5.26x
disk written	0	0
disk read	0	0

1.20x is 1.65x less work per query x 0.65x cores busy during the row (0.65 against 1.00) x 1.00x clock x 1.12x counted on-CPU share: the middle term is occupancy, not search speed d=4 floor: this measures graph traversal and heaps with the distance taken out, not request plumbing (findings 28: 76% of the server's CPU was HNSW search, 24% kernel; the RPC path is a small remainder)

W1 ingest throughput

upload · collection=bench1 · client -p 8 -t 8 -c 1 (-c bfb default) · n=105,100

metric	strawmANN	Qdrant
wall clock	3.2 s	4.7 s	1.47x
of which upload	1.0 s	2.6 s	2.48x
cpu	2.0 s	18.2 s	8.92x
cpu, % of wall	64%	390%
waiting for a core	1.0 ms	7,564.6 ms	7,565.16x
migrations	0	4,367
faults min/maj	225,897 / 0	160,649 / 251,721
peak RSS	1.1 GiB	2.5 GiB	2.33x
disk written	821.1 MiB	2.2 GiB
disk read	0	444.0 KiB

W2 index build time

upload · collection=bench2 · client -p 8 -t 8 -c 1 (-c bfb default) · n=105,100

metric	strawmANN	Qdrant
wall clock	26.2 s	27.3 s	1.04x
of which upload	1.0 s	2.4 s	2.29x
of which index wait	23.1 s	23.1 s	~equal
time to Green	23.1 s	23.1 s	~equal
cpu	167.8 s	144.6 s	0.86x
cpu, % of wall	639%	529%
waiting for a core	99.0 ms	7,150.1 ms	72.22x
migrations	0	5,343
faults min/maj	229,765 / 0	261,652 / 321,681
peak RSS	1.1 GiB	4.0 GiB	3.58x
disk written	821.1 MiB	3.7 GiB
disk read	0	12.0 MiB

W3 search, fp32, single query 1.30x

ef=128 · closed-loop · collection=bench2 · client -p 1 -t 2 -c 1 (-t, -c bfb default) · n=50,000

metric	strawmANN	Qdrant
queries/second	1,281	986	1.30x
recall@10	0.9986	0.9970	~equal
client p50	759 µs	1.00 ms	1.32x
client p99	1.40 ms	1.43 ms	1.02x
client p99.9	1.73 ms	1.54 ms	0.89x
server p50	660 µs	887 µs	1.34x
server p99	1.28 ms	1.31 ms	1.03x
wall clock	39.1 s	50.8 s	1.30x
queries sent	50,000	50,000
cpu	35.6 s	51.7 s	1.45x
cpu, % of wall	91%	102%
waiting for a core	3.3 ms	4.9 ms	1.50x
migrations	0	174
faults min/maj	5 / 0	1,802 / 0
peak RSS	1.1 GiB	4.0 GiB	3.58x
disk written	0	0
disk read	0	0

W4 search, saturating (closed loop) 0.82x

ef=128 · closed-loop · collection=bench2 · client -p 64 -t 16 -c 2 · n=50,000

metric	strawmANN	Qdrant
queries/second	4,656	5,683	0.82x
recall@10	0.9986	0.9970	~equal
client p50	13.69 ms	10.97 ms	0.80x
client p99	15.28 ms	22.55 ms	1.48x
client p99.9	34.24 ms	35.02 ms	1.02x
server p50	13.57 ms	10.44 ms	0.77x
server p99	15.13 ms	18.06 ms	1.19x
wall clock	10.8 s	8.8 s	0.82x
queries sent	50,000	50,000
cpu	77.3 s	69.6 s	0.90x
cpu, % of wall	718%	788%
waiting for a core	7.7 ms	67,279.5 ms	8,776.39x
migrations	0	7,023
faults min/maj	84 / 0	5,372 / 0
peak RSS	1.1 GiB	4.0 GiB	3.58x
disk written	0	0
disk read	0	0

W4-sat50 search, fixed rate at 50% of saturation (open loop) offered

ef=128 · open-loop · offered=2,328/s (50% of saturation, measured 4,656 qps) · collection=bench2 · client -p n/a under --rps -t 16 -c 2 · n=200,000

metric	strawmANN	Qdrant
queries/second	2,328	2,841	offered
recall@10	0.9986	0.9970	~equal
client p50	889 µs	1.12 ms	1.26x
client p99	1.57 ms	2.09 ms	1.33x
client p99.9	1.80 ms	2.49 ms	1.38x
server p50	784 µs	966 µs	1.23x
server p99	1.46 ms	1.91 ms	1.31x
wall clock	86.0 s	70.5 s	0.82x
queries sent	200,000	200,000
cpu	167.8 s	224.8 s	1.34x
cpu, % of wall	195%	319%
waiting for a core	24.3 ms	22,057.5 ms	907.25x
migrations	0	497,175
faults min/maj	12 / 0	3,260 / 0
peak RSS	1.1 GiB	4.0 GiB	3.58x
disk written	0	0
disk read	0	0

W4-sat70 search, fixed rate at 70% of saturation (open loop) offered

ef=128 · open-loop · offered=3,259/s (70% of saturation, measured 4,656 qps) · collection=bench2 · client -p n/a under --rps -t 16 -c 2 · n=200,000

metric	strawmANN	Qdrant
queries/second	3,259	3,978	offered
recall@10	0.9986	0.9970	~equal
client p50	1.01 ms	1.30 ms	1.28x
client p99	2.12 ms	2.65 ms	1.25x
client p99.9	2.47 ms	3.56 ms	1.44x
server p50	903 µs	1.11 ms	1.23x
server p99	1.99 ms	2.38 ms	1.20x
wall clock	61.5 s	50.4 s	0.82x
queries sent	200,000	200,000
cpu	196.9 s	244.4 s	1.24x
cpu, % of wall	320%	485%
waiting for a core	26.2 ms	93,503.0 ms	3,571.19x
migrations	0	583,329
faults min/maj	20 / 0	2,241 / 0
peak RSS	1.1 GiB	4.0 GiB	3.58x
disk written	0	0
disk read	0	0

W4-sat90 search, fixed rate at 90% of saturation (open loop) offered

ef=128 · open-loop · offered=4,191/s (90% of saturation, measured 4,656 qps) · collection=bench2 · client -p n/a under --rps -t 16 -c 2 · n=200,000

metric	strawmANN	Qdrant
queries/second	4,191	5,115	offered
recall@10	0.9986	0.9970	~equal
client p50	1.15 ms	1.91 ms	1.66x
client p99	2.57 ms	8.26 ms	3.21x
client p99.9	3.51 ms	13.36 ms	3.80x
server p50	1.03 ms	1.54 ms	1.49x
server p99	2.42 ms	6.02 ms	2.48x
wall clock	47.9 s	39.2 s	0.82x
queries sent	200,000	200,000
cpu	222.4 s	259.1 s	1.17x
cpu, % of wall	465%	660%
waiting for a core	29.4 ms	161,417.8 ms	5,486.89x
migrations	0	267,514
faults min/maj	48 / 0	2,445 / 0
peak RSS	1.1 GiB	4.0 GiB	3.58x
disk written	0	0
disk read	0	0

W5 search batched (16 distinct dataset queries per request) 2.15x

ef=128 · closed-loop · collection=bench2 · client -p 2 -t 2 -c 1 (-p, -t, -c bfb default) · n=50,000

metric	strawmANN	Qdrant
queries/second	4,656	2,164	2.15x
recall@10	0.9986	0.9970	~equal
client p50	6.86 ms	14.78 ms	2.15x
client p99	8.12 ms	16.64 ms	2.05x
client p99.9	8.55 ms	17.30 ms	2.02x
server p50	6.26 ms	13.98 ms	2.24x
server p99	7.52 ms	15.81 ms	2.10x
wall clock	10.7 s	23.1 s	2.15x
queries sent	50,000	50,000
cpu	76.3 s	45.7 s	0.60x
cpu, % of wall	710%	198%
waiting for a core	7.2 ms	9.6 ms	1.33x
migrations	0	1,280
faults min/maj	0 / 0	1,284 / 0
peak RSS	1.1 GiB	4.0 GiB	3.58x
disk written	0	0
disk read	0	0

per-batch latency (16 queries/request); queries: dataset, random-sample 2.15x is 0.59x less work per query x 3.60x cores busy during the row (7.10 against 1.97) x 1.00x clock x 1.01x counted on-CPU share: the middle term is occupancy, not search speed batched 16, so qps and rps differ by 16x; the ratio uses qps

W6-upload scalar quantization: load

upload · collection=bench6 · client -p 2 -t 2 -c 1 (-p, -t, -c bfb default) · n=105,100

metric	strawmANN	Qdrant
wall clock	88.4 s	24.1 s	0.27x
of which upload	1.0 s	2.9 s	2.82x
of which index wait	85.2 s	19.1 s	0.22x
time to Green	85.2 s	19.1 s	0.22x
cpu	227.9 s	85.1 s	0.37x
cpu, % of wall	258%	354%
waiting for a core	107.3 ms	3,386.9 ms	31.55x
migrations	3	3,619	1,206.33x
faults min/maj	716,129 / 0	432,188 / 355,587
peak RSS	4.0 GiB	6.0 GiB	1.51x
disk written	821.1 MiB	4.6 GiB
disk read	0	14.2 MiB

W6 quantized: scalar 1.33x

ef=128 · closed-loop · collection=bench6 · client -p 2 -t 2 -c 1 (-p, -t, -c bfb default) · n=50,000 · oversampling=12.8 · rescore=true

metric	strawmANN	Qdrant
queries/second	3,621	2,726	1.33x
recall@10	0.9989	0.9974	~equal
client p50	543 µs	728 µs	1.34x
client p99	842 µs	938 µs	1.11x
client p99.9	1.12 ms	1.03 ms	0.92x
server p50	447 µs	609 µs	1.36x
server p99	728 µs	813 µs	1.12x
wall clock	13.8 s	18.4 s	1.33x
queries sent	50,000	50,000
cpu	24.1 s	37.2 s	1.54x
cpu, % of wall	174%	203%
waiting for a core	6.3 ms	10.9 ms	1.71x
migrations	0	14,687
faults min/maj	0 / 0	985 / 0
peak RSS	4.0 GiB	6.0 GiB	1.51x
disk written	0	0
disk read	0	0

W6-ef32 SQ8 recall control, ef=32 (latency only) 1.45x

ef=32 · closed-loop · collection=bench6 · client -p 2 -t 2 -c 1 (-p, -t, -c bfb default) · n=50,000 · oversampling=3.2 · rescore=true

metric	strawmANN	Qdrant
queries/second	7,619	5,268	1.45x
recall@10	0.9947	0.9885	~equal
client p50	240 µs	375 µs	1.56x
client p99	435 µs	464 µs	1.07x
client p99.9	509 µs	563 µs	1.11x
server p50	154 µs	263 µs	1.71x
server p99	325 µs	337 µs	1.04x
wall clock	6.6 s	9.5 s	1.44x
queries sent	50,000	50,000
cpu	10.2 s	19.2 s	1.88x
cpu, % of wall	155%	202%
waiting for a core	2.2 ms	8.5 ms	3.79x
migrations	0	9,455
faults min/maj	0 / 0	122 / 0
peak RSS	4.0 GiB	6.0 GiB	1.51x
disk written	0	0
disk read	0	0

1.45x is 1.76x less work per query x 0.78x cores busy during the row (1.55 against 2.00) x 1.00x clock x 1.06x counted on-CPU share: the middle term is occupancy, not search speed

W6-ef64 SQ8 recall control, ef=64 (latency only) 1.27x

ef=64 · closed-loop · collection=bench6 · client -p 2 -t 2 -c 1 (-p, -t, -c bfb default) · n=50,000 · oversampling=6.4 · rescore=true

metric	strawmANN	Qdrant
queries/second	5,058	3,985	1.27x
recall@10	0.9975	0.9948	~equal
client p50	377 µs	498 µs	1.32x
client p99	700 µs	618 µs	0.88x
client p99.9	793 µs	716 µs	0.90x
server p50	284 µs	385 µs	1.36x
server p99	583 µs	495 µs	0.85x
wall clock	9.9 s	12.6 s	1.27x
queries sent	50,000	50,000
cpu	16.3 s	25.5 s	1.57x
cpu, % of wall	164%	203%
waiting for a core	3.8 ms	9.1 ms	2.38x
migrations	0	11,474
faults min/maj	0 / 0	129 / 0
peak RSS	4.0 GiB	6.0 GiB	1.51x
disk written	0	0
disk read	0	0

W6-ef128 SQ8 recall control, ef=128 (latency only) 1.32x

ef=128 · closed-loop · collection=bench6 · client -p 2 -t 2 -c 1 (-p, -t, -c bfb default) · n=50,000 · oversampling=12.8 · rescore=true

metric	strawmANN	Qdrant
queries/second	3,615	2,731	1.32x
recall@10	0.9989	0.9974	~equal
client p50	543 µs	726 µs	1.34x
client p99	860 µs	936 µs	1.09x
client p99.9	1.14 ms	1.02 ms	0.89x
server p50	447 µs	608 µs	1.36x
server p99	746 µs	811 µs	1.09x
wall clock	13.9 s	18.3 s	1.32x
queries sent	50,000	50,000
cpu	24.2 s	37.3 s	1.54x
cpu, % of wall	175%	203%
waiting for a core	2.9 ms	10.8 ms	3.75x
migrations	0	14,753
faults min/maj	0 / 0	476 / 0
peak RSS	4.0 GiB	6.0 GiB	1.51x
disk written	0	0
disk read	0	0

W6-ef256 SQ8 recall control, ef=256 (latency only) 1.38x

ef=256 · closed-loop · collection=bench6 · client -p 2 -t 2 -c 1 (-p, -t, -c bfb default) · n=50,000 · oversampling=25.6 · rescore=true

metric	strawmANN	Qdrant
queries/second	2,397	1,734	1.38x
recall@10	0.9995	0.9986	~equal
client p50	826 µs	1.14 ms	1.39x
client p99	1.10 ms	1.52 ms	1.38x
client p99.9	1.18 ms	1.63 ms	1.37x
server p50	728 µs	1.02 ms	1.40x
server p99	996 µs	1.39 ms	1.39x
wall clock	20.9 s	28.9 s	1.38x
queries sent	50,000	50,000
cpu	38.2 s	58.5 s	1.53x
cpu, % of wall	183%	202%
waiting for a core	4.2 ms	12.9 ms	3.11x
migrations	0	18,679
faults min/maj	0 / 0	640 / 0
peak RSS	4.0 GiB	6.0 GiB	1.51x
disk written	0	0
disk read	0	0

W6-ef512 SQ8 recall control, ef=512 (latency only) 1.42x

ef=512 · closed-loop · collection=bench6 · client -p 2 -t 2 -c 1 (-p, -t, -c bfb default) · n=50,000 · oversampling=51.2 · rescore=true

metric	strawmANN	Qdrant
queries/second	1,423	1,005	1.42x
recall@10	0.9997	0.9993	~equal
client p50	1.39 ms	1.98 ms	1.42x
client p99	1.86 ms	2.63 ms	1.41x
client p99.9	2.01 ms	2.80 ms	1.39x
server p50	1.29 ms	1.84 ms	1.43x
server p99	1.76 ms	2.49 ms	1.41x
wall clock	35.2 s	49.8 s	1.42x
queries sent	50,000	50,000
cpu	66.7 s	100.7 s	1.51x
cpu, % of wall	190%	202%
waiting for a core	6.3 ms	71.4 ms	11.31x
migrations	0	20,776
faults min/maj	4 / 0	1,376 / 0
peak RSS	4.0 GiB	6.0 GiB	1.51x
disk written	0	0
disk read	0	0

W7-upload binary quantization: load

upload · collection=bench7 · client -p 2 -t 2 -c 1 (-p, -t, -c bfb default) · n=105,100

metric	strawmANN	Qdrant
wall clock	28.3 s	16.1 s	0.57x
of which upload	1.0 s	2.9 s	2.87x
of which index wait	25.1 s	11.0 s	0.44x
time to Green	25.1 s	11.0 s	0.44x
cpu	167.5 s	37.8 s	0.23x
cpu, % of wall	592%	235%
waiting for a core	502.4 ms	2,105.4 ms	4.19x
migrations	5	3,933	786.60x
faults min/maj	237,989 / 0	328,498 / 413,120
peak RSS	4.0 GiB	8.4 GiB	2.10x
disk written	821.1 MiB	4.5 GiB
disk read	0	15.5 MiB

W7 quantized: binary + oversampling parity

ef=128 · closed-loop · collection=bench7 · client -p 2 -t 2 -c 1 (-p, -t, -c bfb default) · n=50,000 · oversampling=12.8 · rescore=true

metric	strawmANN	Qdrant
queries/second	4,352	4,354	parity
recall@10	0.9827	0.9851	~equal
client p50	433 µs	455 µs	1.05x
client p99	677 µs	536 µs	0.79x
client p99.9	841 µs	651 µs	0.77x
server p50	338 µs	342 µs	~equal
server p99	563 µs	401 µs	0.71x
wall clock	11.5 s	11.5 s	~equal
queries sent	50,000	50,000
cpu	19.5 s	23.1 s	1.18x
cpu, % of wall	169%	201%
waiting for a core	5.8 ms	12.1 ms	2.09x
migrations	0	8,960
faults min/maj	0 / 0	506 / 0
peak RSS	4.0 GiB	8.4 GiB	2.10x
disk written	0	0
disk read	0	0

within the ±2.6% band this dataset's noise floor puts on W7: no measured difference, not a small one

W8-upload PQ: load

upload · collection=bench8 · client -p 2 -t 2 -c 1 (-p, -t, -c bfb default) · n=105,100

metric	strawmANN	Qdrant
wall clock	176.7 s	150.2 s	0.85x
of which upload	1.0 s	2.8 s	2.71x
of which index wait	173.6 s	145.4 s	0.84x
time to Green	173.6 s	145.4 s	0.84x
cpu	1,362.4 s	955.9 s	0.70x
cpu, % of wall	771%	636%
waiting for a core	433.9 ms	2,287.5 ms	5.27x
migrations	1	15,664	15,664.00x
faults min/maj	461,956 / 0	252,009 / 287,843
peak RSS	5.4 GiB	8.4 GiB	1.57x
disk written	821.1 MiB	3.6 GiB
disk read	8.0 KiB	13.5 MiB

W8 quantized: PQ 1.30x

ef=128 · closed-loop · collection=bench8 · client -p 2 -t 2 -c 1 (-p, -t, -c bfb default) · n=50,000 · oversampling=12.8 · rescore=true

metric	strawmANN	Qdrant
queries/second	1,452	1,121	1.30x
recall@10	0.9982	0.9963	~equal
client p50	1.36 ms	1.76 ms	1.30x
client p99	1.93 ms	2.26 ms	1.17x
client p99.9	2.28 ms	2.57 ms	1.13x
server p50	1.26 ms	1.62 ms	1.29x
server p99	1.83 ms	2.08 ms	1.14x
wall clock	34.5 s	44.6 s	1.29x
queries sent	50,000	50,000
cpu	65.3 s	89.9 s	1.38x
cpu, % of wall	189%	202%
waiting for a core	4.9 ms	136.5 ms	27.67x
migrations	0	20,325
faults min/maj	0 / 0	5,327 / 0
peak RSS	5.4 GiB	8.4 GiB	1.57x
disk written	0	0
disk read	0	0

W9 exact / brute force parity

exact · closed-loop · collection=bench2 · client -p 8 -t 2 -c 1 (-t, -c bfb default) · n=2,000

metric	strawmANN	Qdrant
queries/second	71	71	parity
client p50	109.30 ms	113.19 ms	1.04x
client p99	164.37 ms	128.73 ms	0.78x
client p99.9	180.92 ms	140.29 ms	0.78x
server p50	108.48 ms	111.83 ms	1.03x
server p99	163.69 ms	127.43 ms	0.78x
wall clock	28.1 s	28.1 s	~equal
queries sent	2,000	2,000
cpu	197.4 s	221.5 s	1.12x
cpu, % of wall	702%	788%
waiting for a core	28.8 ms	11,013.9 ms	382.93x
migrations	0	8,603
faults min/maj	0 / 0	787 / 0
peak RSS	5.4 GiB	8.4 GiB	1.57x
disk written	0	0
disk read	0	0

within the ±3.1% band this dataset's noise floor puts on W9: no measured difference, not a small one brute force over the whole collection, no index involved

W10-ef32 recall control, ef=32 (latency only) 1.15x

ef=32 · closed-loop · collection=bench2 · client -p 8 -t 2 -c 1 (-t, -c bfb default) · n=50,000

metric	strawmANN	Qdrant
queries/second	11,967	10,428	1.15x
recall@10	0.9943	0.9877	~equal
client p50	658 µs	714 µs	1.08x
client p99	983 µs	1.39 ms	1.42x
client p99.9	1.22 ms	1.80 ms	1.48x
server p50	556 µs	540 µs	0.97x
server p99	874 µs	1.16 ms	1.33x
wall clock	4.2 s	4.8 s	1.15x
queries sent	50,000	50,000
cpu	28.9 s	27.9 s	0.96x
cpu, % of wall	686%	576%
waiting for a core	4.6 ms	10,904.3 ms	2,364.29x
migrations	0	72,162
faults min/maj	0 / 0	1,315 / 0
peak RSS	5.4 GiB	8.4 GiB	1.57x
disk written	0	0
disk read	0	0

1.15x is 0.92x less work per query x 1.21x cores busy during the row (6.96 against 5.77) x 1.00x clock x 1.04x counted on-CPU share: the middle term is occupancy, not search speed

W10-ef64 recall control, ef=64 (latency only) 1.05x

ef=64 · closed-loop · collection=bench2 · client -p 8 -t 2 -c 1 (-t, -c bfb default) · n=50,000

metric	strawmANN	Qdrant
queries/second	7,476	7,141	1.05x
recall@10	0.9972	0.9945	~equal
client p50	1.05 ms	1.03 ms	~equal
client p99	1.64 ms	2.06 ms	1.26x
client p99.9	1.87 ms	2.63 ms	1.40x
server p50	946 µs	841 µs	0.89x
server p99	1.53 ms	1.79 ms	1.17x
wall clock	6.7 s	7.0 s	1.05x
queries sent	50,000	50,000
cpu	47.1 s	43.5 s	0.92x
cpu, % of wall	701%	617%
waiting for a core	5.6 ms	28,791.1 ms	5,173.36x
migrations	0	129,916
faults min/maj	0 / 0	973 / 0
peak RSS	5.4 GiB	8.4 GiB	1.57x
disk written	0	0
disk read	0	0

W10-ef128 recall control, ef=128 (latency only) 0.97x

ef=128 · closed-loop · collection=bench2 · client -p 8 -t 2 -c 1 (-t, -c bfb default) · n=50,000

metric	strawmANN	Qdrant
queries/second	4,636	4,791	0.97x
recall@10	0.9986	0.9970	~equal
client p50	1.69 ms	1.56 ms	0.92x
client p99	2.76 ms	3.01 ms	1.09x
client p99.9	3.19 ms	3.83 ms	1.20x
server p50	1.58 ms	1.32 ms	0.83x
server p99	2.65 ms	2.69 ms	~equal
wall clock	10.8 s	10.5 s	0.97x
queries sent	50,000	50,000
cpu	76.5 s	66.2 s	0.86x
cpu, % of wall	707%	632%
waiting for a core	9.1 ms	41,856.1 ms	4,600.43x
migrations	0	150,106
faults min/maj	4 / 0	577 / 0
peak RSS	5.4 GiB	8.4 GiB	1.57x
disk written	0	0
disk read	0	0

W10-ef256 recall control, ef=256 (latency only) 0.91x

ef=256 · closed-loop · collection=bench2 · client -p 8 -t 2 -c 1 (-t, -c bfb default) · n=50,000

metric	strawmANN	Qdrant
queries/second	2,852	3,120	0.91x
recall@10	0.9992	0.9985	~equal
client p50	2.75 ms	2.46 ms	0.89x
client p99	4.63 ms	4.57 ms	~equal
client p99.9	5.37 ms	5.64 ms	1.05x
server p50	2.63 ms	2.19 ms	0.83x
server p99	4.51 ms	4.17 ms	0.92x
wall clock	17.6 s	16.1 s	0.91x
queries sent	50,000	50,000
cpu	124.4 s	105.4 s	0.85x
cpu, % of wall	708%	656%
waiting for a core	13.4 ms	58,014.1 ms	4,315.22x
migrations	0	178,287
faults min/maj	4 / 0	724 / 0
peak RSS	5.4 GiB	8.4 GiB	1.57x
disk written	0	0
disk read	0	0

W10-ef512 recall control, ef=512 (latency only) 0.88x

ef=512 · closed-loop · collection=bench2 · client -p 8 -t 2 -c 1 (-t, -c bfb default) · n=50,000

metric	strawmANN	Qdrant
queries/second	1,731	1,959	0.88x
recall@10	0.9997	0.9993	~equal
client p50	4.52 ms	3.99 ms	0.88x
client p99	7.75 ms	7.07 ms	0.91x
client p99.9	8.93 ms	8.50 ms	0.95x
server p50	4.40 ms	3.69 ms	0.84x
server p99	7.63 ms	6.63 ms	0.87x
wall clock	28.9 s	25.6 s	0.88x
queries sent	50,000	50,000
cpu	204.1 s	174.0 s	0.85x
cpu, % of wall	706%	681%
waiting for a core	22.7 ms	80,763.0 ms	3,558.50x
migrations	0	197,452
faults min/maj	0 / 0	1,495 / 0
peak RSS	5.4 GiB	8.4 GiB	1.57x
disk written	0	0
disk read	0	0

W12-upload filtered search: load 105,100 with payloads

upload · collection=bench12 · client -p 2 -t 2 -c 1 (-p, -t, -c bfb default) · n=105,100

metric	strawmANN	Qdrant
wall clock	26.3 s	50.3 s	1.91x
of which upload	1.1 s	3.7 s	3.53x
of which index wait	23.1 s	44.1 s	1.91x
time to Green	23.1 s	44.1 s	1.91x
cpu	166.8 s	219.2 s	1.31x
cpu, % of wall	634%	436%
waiting for a core	94.9 ms	7,688.9 ms	81.06x
migrations	1	4,185	4,185.00x
faults min/maj	230,557 / 0	214,691 / 352,826
peak RSS	5.6 GiB	8.6 GiB	1.54x
disk written	821.1 MiB	3.7 GiB
disk read	12.0 KiB	24.6 MiB

W12-sel1 filtered search, one keyword (~1% of bench12) parity

ef=128 · closed-loop · collection=bench12 · client -p 2 -t 2 -c 1 (-p, -t, -c bfb default) · n=50,000

metric	strawmANN	Qdrant
queries/second	2,594	2,503	parity
recall@10	1.0000	0.9999	~equal
client p50	767 µs	797 µs	1.04x
client p99	864 µs	949 µs	1.10x
client p99.9	930 µs	1.03 ms	1.10x
server p50	670 µs	675 µs	~equal
server p99	762 µs	809 µs	1.06x
wall clock	19.3 s	20.0 s	1.04x
queries sent	50,000	50,000
cpu	34.8 s	40.6 s	1.17x
cpu, % of wall	180%	203%
waiting for a core	3.0 ms	10.9 ms	3.64x
migrations	0	13,621
faults min/maj	0 / 0	673 / 0
peak RSS	5.6 GiB	8.6 GiB	1.54x
disk written	0	0
disk read	0	0

within the ±9.1% band this dataset's noise floor puts on W12-sel1: no measured difference, not a small one filtered search over a keyword payload index both engines were asked to build; whether each did is read back from the engine and refused beside the row when it did not. Recall is measured under the filter, against ground truth restricted to the matching set

W12-sel10 filtered search, any of 10 keywords (~10% of bench12) parity

ef=128 · closed-loop · collection=bench12 · client -p 2 -t 2 -c 1 (-p, -t, -c bfb default) · n=50,000

metric	strawmANN	Qdrant
queries/second	1,147	1,280	parity
recall@10	0.9991	0.9952	~equal
client p50	1.74 ms	1.57 ms	0.90x
client p99	2.48 ms	1.96 ms	0.79x
client p99.9	2.68 ms	2.08 ms	0.78x
server p50	1.64 ms	1.43 ms	0.87x
server p99	2.38 ms	1.81 ms	0.76x
wall clock	43.6 s	39.1 s	0.90x
queries sent	50,000	50,000
cpu	83.3 s	79.1 s	0.95x
cpu, % of wall	191%	202%
waiting for a core	4.9 ms	48.9 ms	10.07x
migrations	0	20,685
faults min/maj	0 / 0	712 / 0
peak RSS	5.6 GiB	8.6 GiB	1.54x
disk written	0	0
disk read	0	0

within the ±12.7% band this dataset's noise floor puts on W12-sel10: no measured difference, not a small one filtered search over a keyword payload index both engines were asked to build; whether each did is read back from the engine and refused beside the row when it did not. Recall is measured under the filter, against ground truth restricted to the matching set

W12-sel1-ef32 filtered recall control, one keyword, ef=32 (latency only) 0.57x

ef=32 · closed-loop · collection=bench12 · client -p 2 -t 2 -c 1 (-p, -t, -c bfb default) · n=50,000

metric	strawmANN	Qdrant
queries/second	2,605	4,599	0.57x
recall@10	1.0000	0.9974	~equal
client p50	764 µs	433 µs	0.57x
client p99	861 µs	529 µs	0.61x
client p99.9	970 µs	642 µs	0.66x
server p50	668 µs	318 µs	0.48x
server p99	758 µs	395 µs	0.52x
wall clock	19.2 s	10.9 s	0.57x
queries sent	50,000	50,000
cpu	34.7 s	22.1 s	0.64x
cpu, % of wall	180%	202%
waiting for a core	3.2 ms	8.8 ms	2.76x
migrations	0	10,523
faults min/maj	0 / 0	204 / 0
peak RSS	5.6 GiB	8.6 GiB	1.54x
disk written	0	0
disk read	0	0

W12-sel1-ef64 filtered recall control, one keyword, ef=64 (latency only) 0.75x

ef=64 · closed-loop · collection=bench12 · client -p 2 -t 2 -c 1 (-p, -t, -c bfb default) · n=50,000

metric	strawmANN	Qdrant
queries/second	2,599	3,486	0.75x
recall@10	1.0000	0.9996	~equal
client p50	765 µs	574 µs	0.75x
client p99	859 µs	692 µs	0.80x
client p99.9	934 µs	795 µs	0.85x
server p50	668 µs	455 µs	0.68x
server p99	757 µs	555 µs	0.73x
wall clock	19.3 s	14.4 s	0.75x
queries sent	50,000	50,000
cpu	34.7 s	29.2 s	0.84x
cpu, % of wall	180%	203%
waiting for a core	5.1 ms	12.2 ms	2.40x
migrations	0	12,016
faults min/maj	0 / 0	289 / 0
peak RSS	5.6 GiB	8.6 GiB	1.54x
disk written	0	0
disk read	0	0

W12-sel1-ef128 filtered recall control, one keyword, ef=128 (latency only) parity

ef=128 · closed-loop · collection=bench12 · client -p 2 -t 2 -c 1 (-p, -t, -c bfb default) · n=50,000

metric	strawmANN	Qdrant
queries/second	2,612	2,510	parity
recall@10	1.0000	0.9999	~equal
client p50	762 µs	795 µs	1.04x
client p99	848 µs	944 µs	1.11x
client p99.9	939 µs	1.02 ms	1.09x
server p50	665 µs	673 µs	~equal
server p99	743 µs	806 µs	1.08x
wall clock	19.2 s	20.0 s	1.04x
queries sent	50,000	50,000
cpu	34.6 s	40.4 s	1.17x
cpu, % of wall	180%	203%
waiting for a core	2.1 ms	13.2 ms	6.29x
migrations	0	14,175
faults min/maj	0 / 0	292 / 0
peak RSS	5.6 GiB	8.6 GiB	1.54x
disk written	0	0
disk read	0	0

within the ±9.1% band this dataset's noise floor puts on W12-sel1-ef128: no measured difference, not a small one

W12-sel1-ef256 filtered recall control, one keyword, ef=256 (latency only) 1.49x

ef=256 · closed-loop · collection=bench12 · client -p 2 -t 2 -c 1 (-p, -t, -c bfb default) · n=50,000

metric	strawmANN	Qdrant
queries/second	2,593	1,742	1.49x
recall@10	1.0000	1.0000	~equal
client p50	766 µs	1.14 ms	1.49x
client p99	863 µs	1.32 ms	1.53x
client p99.9	936 µs	1.40 ms	1.50x
server p50	669 µs	1.02 ms	1.52x
server p99	756 µs	1.18 ms	1.56x
wall clock	19.3 s	28.7 s	1.49x
queries sent	50,000	50,000
cpu	34.7 s	58.1 s	1.67x
cpu, % of wall	179%	202%
waiting for a core	1.9 ms	20.9 ms	10.85x
migrations	0	14,920
faults min/maj	0 / 0	593 / 0
peak RSS	5.6 GiB	8.6 GiB	1.54x
disk written	0	0
disk read	0	0

W12-sel1-ef512 filtered recall control, one keyword, ef=512 (latency only) 2.29x

ef=512 · closed-loop · collection=bench12 · client -p 2 -t 2 -c 1 (-p, -t, -c bfb default) · n=50,000

metric	strawmANN	Qdrant
queries/second	2,606	1,137	2.29x
recall@10	1.0000	1.0000	~equal
client p50	763 µs	1.76 ms	2.30x
client p99	857 µs	1.95 ms	2.27x
client p99.9	936 µs	2.07 ms	2.21x
server p50	666 µs	1.62 ms	2.43x
server p99	751 µs	1.79 ms	2.38x
wall clock	19.2 s	44.0 s	2.29x
queries sent	50,000	50,000
cpu	34.6 s	88.2 s	2.55x
cpu, % of wall	180%	200%
waiting for a core	5.1 ms	117.3 ms	23.01x
migrations	0	13,954
faults min/maj	0 / 0	942 / 0
peak RSS	5.6 GiB	8.6 GiB	1.54x
disk written	0	0
disk read	0	0

W12-sel10-ef32 filtered recall control, any of 10 keywords, ef=32 (latency only)

ef=32 · closed-loop · collection=bench12 · client -p 2 -t 2 -c 1 (-p, -t, -c bfb default) · n=50,000

metric	strawmANN	Qdrant
queries/second	2,583	2,998	-
recall@10	0.9929	0.8703
client p50	767 µs	661 µs
client p99	1.05 ms	862 µs
client p99.9	1.24 ms	965 µs
server p50	670 µs	537 µs
server p99	952 µs	726 µs
wall clock	19.4 s	16.7 s
queries sent	50,000	50,000
cpu	35.2 s	33.8 s
cpu, % of wall	182%	202%
waiting for a core	9.3 ms	10.3 ms
migrations	0	14,208
faults min/maj	0 / 0	538 / 0
peak RSS	5.6 GiB	8.6 GiB
disk written	0	0
disk read	0	0

recall unequal: 0.9929 vs 0.8703; §7.4 compares at equal recall

W12-sel10-ef64 filtered recall control, any of 10 keywords, ef=64 (latency only)

ef=64 · closed-loop · collection=bench12 · client -p 2 -t 2 -c 1 (-p, -t, -c bfb default) · n=50,000

metric	strawmANN	Qdrant
queries/second	1,761	2,081	-
recall@10	0.9975	0.9666
client p50	1.13 ms	963 µs
client p99	1.59 ms	1.20 ms
client p99.9	1.75 ms	1.31 ms
server p50	1.03 ms	834 µs
server p99	1.49 ms	1.06 ms
wall clock	28.4 s	24.1 s
queries sent	50,000	50,000
cpu	53.1 s	48.7 s
cpu, % of wall	187%	202%
waiting for a core	3.9 ms	16.8 ms
migrations	0	16,801
faults min/maj	0 / 0	266 / 0
peak RSS	5.6 GiB	8.6 GiB
disk written	0	0
disk read	0	0

recall unequal: 0.9975 vs 0.9666; §7.4 compares at equal recall

W12-sel10-ef128 filtered recall control, any of 10 keywords, ef=128 (latency only) parity

ef=128 · closed-loop · collection=bench12 · client -p 2 -t 2 -c 1 (-p, -t, -c bfb default) · n=50,000

metric	strawmANN	Qdrant
queries/second	1,146	1,268	parity
recall@10	0.9991	0.9952	~equal
client p50	1.75 ms	1.59 ms	0.91x
client p99	2.49 ms	1.97 ms	0.79x
client p99.9	2.70 ms	2.09 ms	0.77x
server p50	1.64 ms	1.45 ms	0.88x
server p99	2.38 ms	1.81 ms	0.76x
wall clock	43.7 s	39.5 s	0.90x
queries sent	50,000	50,000
cpu	83.5 s	79.8 s	0.96x
cpu, % of wall	191%	202%
waiting for a core	5.6 ms	62.9 ms	11.16x
migrations	0	20,657
faults min/maj	0 / 0	940 / 0
peak RSS	5.6 GiB	8.6 GiB	1.54x
disk written	0	0
disk read	0	0

within the ±12.7% band this dataset's noise floor puts on W12-sel10-ef128: no measured difference, not a small one

W12-sel10-ef256 filtered recall control, any of 10 keywords, ef=256 (latency only) 0.52x

ef=256 · closed-loop · collection=bench12 · client -p 2 -t 2 -c 1 (-p, -t, -c bfb default) · n=50,000

metric	strawmANN	Qdrant
queries/second	408	784	0.52x
recall@10	1.0000	0.9992	~equal
client p50	4.88 ms	2.59 ms	0.53x
client p99	5.61 ms	3.18 ms	0.57x
client p99.9	5.90 ms	3.34 ms	0.57x
server p50	4.56 ms	2.43 ms	0.53x
server p99	4.98 ms	3.02 ms	0.61x
wall clock	122.6 s	63.8 s	0.52x
queries sent	50,000	50,000
cpu	231.5 s	128.6 s	0.56x
cpu, % of wall	189%	202%
waiting for a core	31.8 ms	76.6 ms	2.41x
migrations	0	19,993
faults min/maj	0 / 0	1,458 / 0
peak RSS	5.6 GiB	8.6 GiB	1.54x
disk written	0	0
disk read	0	0

W12-sel10-ef512 filtered recall control, any of 10 keywords, ef=512 (latency only) 0.85x

ef=512 · closed-loop · collection=bench12 · client -p 2 -t 2 -c 1 (-p, -t, -c bfb default) · n=50,000

metric	strawmANN	Qdrant
queries/second	414	486	0.85x
recall@10	1.0000	0.9999	~equal
client p50	4.81 ms	4.17 ms	0.87x
client p99	5.34 ms	5.16 ms	0.97x
client p99.9	5.67 ms	5.41 ms	0.95x
server p50	4.55 ms	3.96 ms	0.87x
server p99	4.99 ms	4.92 ms	~equal
wall clock	120.7 s	102.8 s	0.85x
queries sent	50,000	50,000
cpu	231.3 s	204.8 s	0.89x
cpu, % of wall	192%	199%
waiting for a core	35.0 ms	87.0 ms	2.49x
migrations	0	22,174
faults min/maj	0 / 0	2,574 / 0
peak RSS	5.6 GiB	8.6 GiB	1.54x
disk written	0	0
disk read	0	0

W13 scroll / pagination 1.09x

closed-loop · collection=bench2 · client -p 8 -t 2 -c 1 (-t, -c bfb default) · n=200,000

metric	strawmANN	Qdrant
queries/second	50,845	46,450	1.09x
client p50	138 µs	158 µs	1.15x
client p99	232 µs	304 µs	1.31x
client p99.9	276 µs	466 µs	1.69x
server p50	11 µs	28 µs	2.59x
server p99	16 µs	95 µs	5.85x
wall clock	4.1 s	2.2 s	0.55x
queries sent	200,000	100,000
cpu	5.6 s	9.2 s	1.65x
cpu, % of wall	137%	414%
waiting for a core	2.4 ms	932.5 ms	396.38x
migrations	0	112,908
faults min/maj	0 / 0	425 / 0
peak RSS	5.6 GiB	8.6 GiB	1.54x
disk written	0	0
disk read	0	0

strawmANN: -n 200000 (4x the table's 50000) Qdrant: -n 100000 (2x the table's 50000) strawmANN: 0.13 ms of the client's 0.14 ms p50 is not server time (13x), so 92% of this row is the load generator and the socket Qdrant: 0.13 ms of the client's 0.16 ms p50 is not server time (6x), so 82% of this row is the load generator and the socket 1.09x is 3.29x less work per query x 0.33x cores busy during the row (1.39 against 4.24) x 1.00x clock x 1.02x counted on-CPU share: the middle term is occupancy, not search speed

W11-steady mixed read/write below the rebuild threshold: search bench2 while 5,255 synthetic points append

ef=128 · closed-loop · collection=bench2 · client -p 8 -t 2 -c 1 (-t, -c bfb default) · n=50,000

metric	strawmANN	Qdrant
queries/second	2,388	3,857	-
client p50	3.10 ms	1.83 ms
client p99	6.75 ms	5.33 ms
client p99.9	7.80 ms	16.33 ms
server p50	2.98 ms	1.52 ms
server p99	6.62 ms	4.66 ms
wall clock	21.0 s	13.0 s
queries sent	50,000	50,000
cpu	147.1 s	96.9 s
cpu, % of wall	701%	745%
waiting for a core	20.7 ms	77,335.9 ms
migrations	0	171,847
faults min/maj	12,338 / 0	403,201 / 130,786
peak RSS	5.6 GiB	8.6 GiB
disk written	41.2 MiB	5.9 GiB
disk read	0	38.3 MiB

strawmANN: search covered 79% of the append; append 198 points/s Qdrant: search covered 49% of the append; append 198 points/s search-during-write; no recall join

W11 mixed read/write: search bench2 while 21,020 synthetic points append (runs last)

ef=128 · closed-loop · collection=bench2 · client -p 8 -t 2 -c 1 (-t, -c bfb default) · n=50,000

metric	strawmANN	Qdrant
queries/second	623	3,453	-
client p50	10.83 ms	2.07 ms
client p99	27.03 ms	6.82 ms
client p99.9	31.01 ms	17.67 ms
server p50	10.64 ms	1.69 ms
server p99	26.34 ms	5.84 ms
wall clock	80.3 s	14.5 s
queries sent	50,000	50,000
cpu	606.7 s	156.9 s
cpu, % of wall	756%	1,081%
waiting for a core	309,613.4 ms	100,964.5 ms
migrations	71	182,017
faults min/maj	58,385 / 0	1,670,641 / 591,145
peak RSS	5.6 GiB	23.8 GiB
disk written	164.5 MiB	25.7 GiB
disk read	0	152.9 MiB

strawmANN: write overlap 88%; append 299 points/s Qdrant: search covered 21% of the append; append 299 points/s search-during-write; no recall join; the writer covered under 90% of strawmANN's search, so the last 12% of that row measured the rebuild the append provoked rather than a concurrent write

Host discipline the §7.1 gate, per check, and ambient load per row

Ambient load per row

The §7.1 gate checks the machine once, at the start. Colour is the engine, as everywhere else; a hatched bar with a red edge is a row that had another process on the box while it ran, which the gate cannot see.

AMD Ryzen AI 9 HX PRO 370 w/ Radeon 890M (24 logical) gate pass

One machine: both runs were measured on it, and the checks below are the same for both. What differed at each run start is listed underneath, per run.

okAMD Ryzen AI 9 HX PRO 370 w/ Radeon 890M (24 logical)

okgovernor=performance

okboost disabled

oksmt=on

declared rather than required (§7.1 asks for SMT on or off, not

for off), and hashed, so these rows never share a chart with

SMT-off ones

cpu N and cpu N+12 share a core (12 pairs);

a --server-cpus or --client-cpus set holding both cpus of a

pair measures the engine on half the cores it names

okprofile=as-deployed (isolcpus=none nohz_full=none)

the scheduler is running as it ships, so these numbers describe a

deployment rather than the engine in isolation; they may not be

compared against an `isolated` run, and the environment hash

enforces that

okthp=madvise numa_nodes=1 numa_balancing=0

okperf_event_paranoid=-1

oktask_delayacct=1, so time blocked on a device is measurable

okperf at /usr/bin/perf, so `workloads.py run --perf` can attach

okcgroup io controller reaches the engines' own scope, so block-layer read/write operations are measurable

okzig=0.16.0

busy: Xorg(6%)

measurement profile: as-deployed

strawmANN at run start · environment hash 373e8531fd3d1bf6

Qdrant at run start · environment hash 373e8531fd3d1bf6

What this does not establish

No Qdrant developer has used this tool. Nothing here has been run, checked against something already known, or disagreed with by anyone outside the project: every number has one author and one reviewer, and they are the same person. A result you can refute is more useful to us than one you accept.

It has never been pointed at a real Qdrant regression. The harness detects a known ISA slowdown and correctly reports no difference on a control row. That is internal consistency, not evidence it would flag a regression in your tree or stay quiet through a refactor. bench/harness/qdrant_ab.py exists to run two of your commits through it blind, and that experiment has not been done.

Part of the measured throughput gap is kernel width, not architecture. Read from a dev checkout: Qdrant's distance path tops out at four 256-bit accumulators and has no AVX-512, while these kernels use 512-bit ones on a machine that has them. That is a real difference and it is not the same claim as "the design is faster".

The engines are not equivalent, by construction. §1 removes sharding, replication, consensus, snapshots, sparse vectors, multivectors and disk-resident operation — permanently. Payload storage and filtering were in that list until 2026-09-03 and are now built (M7), so W12 measures a filtered search with a keyword index on both engines. Anything still unbuilt answers UNIMPLEMENTED naming the construct and reports n/a, never a silent degradation. A strawman that was not faster would mean it was badly built; the question is by how much, and where the model was wrong.

Reproducing this

Everything below runs from a clone. The engine has no dependencies; the analysis path is a uv project pinned by bench/uv.lock.

scripts/doctor.py                    # what can this machine measure?
bench/setup.py check                 # §7.1 host gate: governor, boost, isolation, idle
conformance/datasets/datasets.py fetch

# one engine at a time, §7.1
zig build -Doptimize=ReleaseFast
# --connections matters: W4 opens ~32 sockets (-t 16 -c 2) and a server with
# fewer closes the excess before the HTTP/2 preface, which the client reports
# only as "transport error".
./zig-out/bin/strawmann --port 6334 --connections 64
bench/harness/workloads.py run http://localhost:6334 strawmann --sink --report

# the other half of every number: recall, and the licence to compare at all
cd conformance
cargo run --release -- relevance --engine http://localhost:6334 --label strawmann \
  --base $DATA/sift1m.fbin --queries $DATA/sift1m_query.fbin \
  --ground-truth $DATA/gt/sift1m.euclid.k100.gt.json --metric euclid \
  --ef 32 64 128 256 512 --json ../bench/results/strawmann/recall.json
cargo run --release -- differ --strawmann http://localhost:6334 --qdrant http://localhost:6434 \
  --base $DATA/sift1m.fbin --queries $DATA/sift1m_query.fbin \
  --ground-truth $DATA/gt/sift1m.euclid.k100.gt.json \
  --json ../bench/results/strawmann/conformance.json

uv run --project bench bench/harness/report.py strawmann qdrant

Disagreements are the point. docs/spec.md is what all of this is measured against, docs/bugs.md lists the measurement bugs found so far (each produced a plausible wrong number rather than a failure), and docs/validation.md records what has and has not been checked.

Generated by bench/harness/report.py from bench/results/. Self-contained: charts are embedded, nothing is fetched at open time. Regenerate with uv run --project bench bench/harness/report.py sm-hnm-perf-0929 qd-hnm-perf-0929.

Summary

Throughput against recall

Throughput

Throughput by workload

Recall

At matched recall

At matched recall, SQ8

At matched recall, filtered to 10%

Recall by ef

What each quantization costs in recall

Latency

Ingest and index build

Where the load time goes

Memory and disk

Appendix

Dataset

Host §7.1 gate pass

W10: throughput against ef

Per workload

Time spent waiting for a core

Peak memory per row

Time stalled on I/O

What one query cost, in cycles

Demand loads from DRAM per query

TLB walks per query

Instructions per cycle

Branch mispredictions per 1k instructions

W0-upload transport floor: load

W0 d=4 floor: graph traversal with the distance taken out 1.20x

W1 ingest throughput

W2 index build time

W3 search, fp32, single query 1.30x

W4 search, saturating (closed loop) 0.82x

W4-sat50 search, fixed rate at 50% of saturation (open loop) offered

W4-sat70 search, fixed rate at 70% of saturation (open loop) offered

W4-sat90 search, fixed rate at 90% of saturation (open loop) offered

W5 search batched (16 distinct dataset queries per request) 2.15x

W6-upload scalar quantization: load

W6 quantized: scalar 1.33x

W6-ef32 SQ8 recall control, ef=32 (latency only) 1.45x

W6-ef64 SQ8 recall control, ef=64 (latency only) 1.27x

W6-ef128 SQ8 recall control, ef=128 (latency only) 1.32x

W6-ef256 SQ8 recall control, ef=256 (latency only) 1.38x

W6-ef512 SQ8 recall control, ef=512 (latency only) 1.42x

W7-upload binary quantization: load

W7 quantized: binary + oversampling parity

W8-upload PQ: load

W8 quantized: PQ 1.30x

W9 exact / brute force parity

W10-ef32 recall control, ef=32 (latency only) 1.15x

W10-ef64 recall control, ef=64 (latency only) 1.05x

W10-ef128 recall control, ef=128 (latency only) 0.97x

W10-ef256 recall control, ef=256 (latency only) 0.91x

W10-ef512 recall control, ef=512 (latency only) 0.88x

W12-upload filtered search: load 105,100 with payloads

W12-sel1 filtered search, one keyword (~1% of bench12) parity

W12-sel10 filtered search, any of 10 keywords (~10% of bench12) parity

W12-sel1-ef32 filtered recall control, one keyword, ef=32 (latency only) 0.57x

W12-sel1-ef64 filtered recall control, one keyword, ef=64 (latency only) 0.75x

W12-sel1-ef128 filtered recall control, one keyword, ef=128 (latency only) parity

W12-sel1-ef256 filtered recall control, one keyword, ef=256 (latency only) 1.49x

W12-sel1-ef512 filtered recall control, one keyword, ef=512 (latency only) 2.29x

W12-sel10-ef32 filtered recall control, any of 10 keywords, ef=32 (latency only)

W12-sel10-ef64 filtered recall control, any of 10 keywords, ef=64 (latency only)

W12-sel10-ef128 filtered recall control, any of 10 keywords, ef=128 (latency only) parity

W12-sel10-ef256 filtered recall control, any of 10 keywords, ef=256 (latency only) 0.52x

W12-sel10-ef512 filtered recall control, any of 10 keywords, ef=512 (latency only) 0.85x

W13 scroll / pagination 1.09x

W11-steady mixed read/write below the rebuild threshold: search bench2 while 5,255 synthetic points append

W11 mixed read/write: search bench2 while 21,020 synthetic points append (runs last)

Ambient load per row

AMD Ryzen AI 9 HX PRO 370 w/ Radeon 890M (24 logical) gate pass

Recall by `ef`