strawmANN benchmark report

strawmANN against Qdrant · AMD Ryzen AI 9 HX PRO 370 w/ Radeon 890M (24 logical) · generated 2026-09-30 06:41:52 CEST

Dataset: dbpedia-openai-1m
Vectors: 1,000,000 × 1,536 · 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.09x to 1.40x Qdrant's throughput. That range spans the recall levels measured; allowing for the uncertainty in each recall figure widens it to 0.90x to 1.53x.

throughput at equal recall

1.09 to 1.40x

strawmANN over Qdrant, recall@10 0.895 to 0.989

p99 latency at 90% load

strawmANN2.83 ms

Qdrant9.53 ms

W4-sat90, open loop, one offered rate

upload and index build

strawmANN260 s

Qdrant404 s

W1 + W2

peak memory (RSS)

strawmANN31.6 GiB

Qdrant43.6 GiB

largest before the concurrent-write rows (W11); of it, anonymous 4.0 GiB / 3.4 GiB

written to disk

strawmANN29.5 GiB

Qdrant134.1 GiB

before the concurrent-write rows (W11); they wrote 1.4 GiB / 21.4 GiB more

Where strawmANN is slower, past the noise floor:

filtered recall control, one keyword, ef=64 (latency only) (W12-sel1-ef64): 0.77x, strawmANN at recall 1.0000, Qdrant at 0.9965

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,060	624	1.70x
W4	search, saturating (closed loop)	3,556	3,483	1.02x
W5	search batched (16 distinct dataset queries per request)	3,530221 requests/s	1,30382 requests/s	2.71x
W6	quantized: scalar	3,028	2,026	1.50x
W6 ef 32 to 512	SQ8 recall control (latency only)	1,063 to 6,051	674 to 4,361	1.37 to 1.58x
W7	quantized: binary + oversampling	4,168	3,579	1.16x
W8	quantized: PQ	1,482	1,106	1.34x
W9	exact / brute force	13	10	1.33x
W10 ef 32 to 512	recall control (latency only)	1,235 to 10,625	1,068 to 7,358	1.16 to 1.44x
W12-sel1	filtered search, one keyword (~1% of bench12)	1,869	1,616	1.16x
W12-sel10	filtered search, any of 10 keywords (~10% of bench12)	822	823	-	recall differs: 0.9893 vs 0.9720
W12-sel1 ef 32 to 512	filtered recall control, one keyword (latency only)	1,861 to 1,864	758 to 3,397	0.77 to 2.45x	1 of 5 points not compared recall differs
W12-sel10 ef 32 to 512	filtered recall control, any of 10 keywords (latency only)	294 to 1,974	286 to 2,259	parity	3 of 5 points not compared recall differs
W13	scroll / pagination	51,141	46,852	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 49,500 synthetic points append	580	504237 requests/s	-	search-during-write; no recall join
W11	mixed read/write: search bench2 while 198,000 synthetic points append (runs last)	251	99	-	search-during-write; no recall join

Throughput by workload

Higher is better. Hatched bars are rows the table does not compare (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.8945	Qdrant at ef=32, strawmANN interpolated	10,273	7,358	1.40x	1.28 – 1.53x
0.9399	strawmANN at ef=64, Qdrant interpolated	6,481	5,037	1.29x	1.24 – 1.34x
0.9441	Qdrant at ef=64, strawmANN interpolated	5,967	4,865	1.23x	1.09 – 1.38x
0.9667	strawmANN at ef=128, Qdrant interpolated	3,799	3,227	1.18x	1.10 – 1.26x
0.9694	Qdrant at ef=128, strawmANN interpolated	3,427	3,074	1.11x	0.96 – 1.30x
0.9812	strawmANN at ef=256, Qdrant interpolated	2,181	1,933	1.13x	1.01 – 1.26x
0.9822	Qdrant at ef=256, strawmANN interpolated	2,024	1,854	1.09x	0.90 – 1.32x
0.9892	strawmANN at ef=512, Qdrant interpolated	1,235	1,137	1.09x	0.93 – 1.27x

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.8918	strawmANN at ef=32, Qdrant interpolated	6,051	4,326	1.40x	1.34 – 1.46x
0.9393	strawmANN at ef=64, Qdrant interpolated	4,266	3,150	1.35x	1.31 – 1.40x
0.9413	Qdrant at ef=64, strawmANN interpolated	4,161	3,109	1.34x	1.24 – 1.45x
0.9669	strawmANN at ef=128, Qdrant interpolated	3,022	2,061	1.47x	1.38 – 1.56x
0.9682	Qdrant at ef=128, strawmANN interpolated	2,888	2,018	1.43x	1.22 – 1.68x
0.9811	strawmANN at ef=256, Qdrant interpolated	1,841	1,204	1.53x	1.36 – 1.72x
0.9820	Qdrant at ef=256, strawmANN interpolated	1,739	1,164	1.49x	1.19 – 1.88x
0.9895	strawmANN at ef=512, Qdrant interpolated	1,063	700	1.52x	1.31 – 1.76x

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, 19,997 to 20,119 across 3 builds in strawmANN and 19,982 to 20,188 across 3 builds 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.9383	strawmANN at ef=32, Qdrant interpolated	1,974	1,056	1.87x	1.80 – 1.94x
0.9720	Qdrant at ef=128, strawmANN interpolated	1,325	822	1.61x	1.54 – 1.68x
0.9728	strawmANN at ef=64, Qdrant interpolated	1,312	807	1.63x	1.48 – 1.79x
0.9893	strawmANN at ef=128, Qdrant interpolated	822	549	1.50x	1.41 – 1.59x
0.9945	Qdrant at ef=256, strawmANN interpolated	536	486	1.10x	0.96 – 1.27x
0.9959	strawmANN at ef=256, Qdrant interpolated	480	415	1.16x	0.98 – 1.37x
0.9991	Qdrant at ef=512, strawmANN interpolated	328	286	1.15x	1.06 – 1.24x

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.8949	0.8912	-	1.86e-03	0.9006	0.8945	-	1.78e-03
ef=64	0.9378	0.9399	-	8.97e-04	0.9398	0.9441	-	8.27e-04
ef=128	0.9658	0.9667	0.9291	4.73e-04	0.9672	0.9694	0.9314	4.27e-04
ef=256	0.9803	0.9812	0.9658	2.54e-04	0.9810	0.9822	0.9678	2.44e-04
ef=512	0.9891	0.9892	0.9834	1.43e-04	0.9899	0.9901	0.9848	1.34e-04

How recall was measured

10,000 held-out queries, limit 10, ε=9.537e-07, against the fp64 oracle rather than against the other engine. Base checksum 71f1df815731cdbf: 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.00035; Qdrant 0.00033. Over the same builds the engine reported unreachable nodes: strawmANN 0 of 200,000 and 0 of 990,000 — 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.

workload	strawmANN			Qdrant
workload	p50	p99	p99.9	p50	p99	p99.9
W3 search, fp32, single query	947 µs	1.37 ms	1.89 ms	1.60 ms	2.29 ms	2.57 ms
W4-sat50 search, fixed rate at 50% of saturation (open loop)	1.03 ms	1.63 ms	1.87 ms	1.76 ms	2.95 ms	3.77 ms
W4-sat70 search, fixed rate at 70% of saturation (open loop)	1.11 ms	1.95 ms	2.29 ms	2.00 ms	3.75 ms	4.76 ms
W4-sat90 search, fixed rate at 90% of saturation (open loop)	1.39 ms	2.83 ms	3.56 ms	2.70 ms	9.53 ms	17.91 ms
W5 search batched (16 distinct dataset queries per request)	9.06 ms	10.55 ms	11.31 ms	24.54 ms	27.79 ms	28.86 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	17.05 s	22.05 s
W1	ingest throughput (no index wait)	5.53 s	33.59 s
W2	index build, time to Green	254.86 s	370.89 s
W6-upload	search, SQ8 scalar quantization	258.85 s	176.40 s
W7-upload	search, binary quantization	263.93 s	89.19 s
W8-upload	search, product quantization	359.29 s	875.15 s
W12-upload	upload	39.12 s	90.22 s
W1 + W2	upload and index, together	260.4 s	404.5 s	1.55x

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	35.5 GiB	26.5 GiB
peak memory (RSS)	31.6 GiB	43.6 GiB
read from disk	86.0 MiB	1.2 GiB
written to disk	29.5 GiB	134.1 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 2880404844a92b92.

On exact search the two engines' scores differ by at most 3.576e-07 (p99 1.788e-07), against a calibrated absolute ε of 9.537e-07. §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 does not order the engines consistently (0.71x to 2.73x); 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-dbp1m-perf-0930`	Qdrant `qd-dbp1m-perf-0930`
engine	commit `1fb2e437e858` `ReleaseFast`, native build, vnni on binary sha256 `e9f47255fbea5cee` built 2026-09-29T15:06:47Z 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-29T20:30:39Z to 2026-09-30T02:27:34Z (3 passes)	2026-09-29T21:34:47Z to 2026-09-30T03:49:45Z (3 passes)
profile	`as-deployed` · both engines
§7.1 gate	pass · both engines
environment hash	`373e8531fd3d1bf6` · 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 1237500 --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

dbpedia-openai-1m, 1000000 × 1536, cosine, 10000 held-out queries

ground truth: recomputed by our fp64 oracle

26 files, each pinned by sha256 in datasets.json

Host

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

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

memory bandwidth: 73.6 GB/s aggregate (24 threads) · 45.9 GB/s single core (62% of bus)

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

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,598	3,495	1.32x	1.32x is 1.83x less work per query x 0.67x cores busy during the row (0.67 against 1.01) x 1.00x clock x 1.08x 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,060	624	1.70x
W4	search, saturating (closed loop)	3,556	3,483	1.02x
W4-sat50	search, fixed rate at 50% of saturation (open loop)	1,741	1,741	offered
W4-sat70	search, fixed rate at 70% of saturation (open loop)	2,437	2,437	offered
W4-sat90	search, fixed rate at 90% of saturation (open loop)	3,133	3,133	offered
W5	search batched (16 distinct dataset queries per request)	3,530221 requests/s	1,30382 requests/s	2.71x	per-batch latency (16 queries/request); queries: dataset, random-sample 2.71x is 0.75x less work per query x 3.58x cores busy during the row (7.07 against 1.97) x 1.00x clock: 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,028	2,026	1.50x
W6-ef32	SQ8 recall control, ef=32 (latency only)	6,051	4,361	1.39x	1.39x is 1.70x less work per query x 0.79x cores busy during the row (1.59 against 2.02) x 1.00x clock x 1.04x counted on-CPU share: the middle term is occupancy, not search speed
W6-ef64	SQ8 recall control, ef=64 (latency only)	4,266	3,109	1.37x
W6-ef128	SQ8 recall control, ef=128 (latency only)	3,022	2,018	1.50x
W6-ef256	SQ8 recall control, ef=256 (latency only)	1,841	1,164	1.58x
W6-ef512	SQ8 recall control, ef=512 (latency only)	1,063	674	1.58x
W7	quantized: binary + oversampling	4,168	3,579	1.16x
W8	quantized: PQ	1,482	1,106	1.34x
W9	exact / brute force	13	10	1.33x	1.33x is 2.62x less work per query x 0.53x cores busy during the row (4.20 against 7.98) x 1.00x clock x 0.97x counted on-CPU share: the middle term is occupancy, not search speed brute force over the whole collection, no index involved
W10-ef32	recall control, ef=32 (latency only)	10,625	7,358	1.44x
W10-ef64	recall control, ef=64 (latency only)	6,481	4,865	1.33x
W10-ef128	recall control, ef=128 (latency only)	3,799	3,074	1.24x
W10-ef256	recall control, ef=256 (latency only)	2,181	1,854	1.18x
W10-ef512	recall control, ef=512 (latency only)	1,235	1,068	1.16x
W12-sel1	filtered search, one keyword (~1% of bench12)	1,869	1,616	1.16x	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)	822	823	-	recall unequal: 0.9893 vs 0.9720; §7.4 compares at equal recall 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)	1,864	3,397	-	recall unequal: 1.0000 vs 0.9804; §7.4 compares at equal recall
W12-sel1-ef64	filtered recall control, one keyword, ef=64 (latency only)	1,862	2,412	0.77x
W12-sel1-ef128	filtered recall control, one keyword, ef=128 (latency only)	1,864	1,636	1.14x
W12-sel1-ef256	filtered recall control, one keyword, ef=256 (latency only)	1,864	1,083	1.72x
W12-sel1-ef512	filtered recall control, one keyword, ef=512 (latency only)	1,861	758	2.45x
W12-sel10-ef32	filtered recall control, any of 10 keywords, ef=32 (latency only)	1,974	2,259	-	recall unequal: 0.9383 vs 0.7668; §7.4 compares at equal recall
W12-sel10-ef64	filtered recall control, any of 10 keywords, ef=64 (latency only)	1,312	1,400	-	recall unequal: 0.9728 vs 0.9005; §7.4 compares at equal recall
W12-sel10-ef128	filtered recall control, any of 10 keywords, ef=128 (latency only)	822	822	-	recall unequal: 0.9893 vs 0.9720; §7.4 compares at equal recall
W12-sel10-ef256	filtered recall control, any of 10 keywords, ef=256 (latency only)	480	486	parity	within the ±4.5% band this dataset's noise floor puts on W12-sel10-ef256: no measured difference, not a small one
W12-sel10-ef512	filtered recall control, any of 10 keywords, ef=512 (latency only)	294	286	parity	within the ±4.9% band this dataset's noise floor puts on W12-sel10-ef512: no measured difference, not a small one
W13	scroll / pagination	51,141	46,852	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 (12x), 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.25x less work per query x 0.33x cores busy during the row (1.40 against 4.23) 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 49,500 synthetic points append	580	504237 requests/s	-	strawmANN: qps over the 26.1 s the append ran (726 over the whole search); append 1,900 points/s Qdrant: qps over the 26.0 s the append ran (272 over the whole search); append 1,900 points/s search-during-write; no recall join
W11	mixed read/write: search bench2 while 198,000 synthetic points append (runs last)	251	99	-	strawmANN: qps over the 31.7 s the append ran (251 over the whole search); write overlap 53%; search covered 53% of the append; append 3,300 points/s Qdrant: qps over the 82.1 s the append ran (97 over the whole search); search covered 97% of the append; append 2,396 points/s search-during-write; no recall join; the search saw under 90% of strawmANN's append, so its qps is the append's start and not all of it

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	213 µs	240 µs	261 µs	305 µs	891 µs	285 µs	319 µs	348 µs	400 µs	1.44 ms
W3	search, fp32, single query closed loop	947 µs	1.21 ms	1.37 ms	1.89 ms	2.58 ms	1.60 ms	2.14 ms	2.29 ms	2.57 ms	4.63 ms
W4	search, saturating (closed loop) closed loop	18.05 ms	19.55 ms	20.22 ms	26.83 ms	39.91 ms	18.14 ms	23.96 ms	32.49 ms	43.64 ms	67.50 ms
W4-sat50	search, fixed rate at 50% of saturation (open loop) open loop	1.03 ms	1.38 ms	1.63 ms	1.87 ms	5.92 ms	1.76 ms	2.41 ms	2.95 ms	3.77 ms	8.13 ms
W4-sat70	search, fixed rate at 70% of saturation (open loop) open loop	1.11 ms	1.57 ms	1.95 ms	2.29 ms	6.69 ms	2.00 ms	3.11 ms	3.75 ms	4.76 ms	14.11 ms
W4-sat90	search, fixed rate at 90% of saturation (open loop) open loop	1.39 ms	2.36 ms	2.83 ms	3.56 ms	7.69 ms	2.70 ms	4.89 ms	9.53 ms	17.91 ms	35.03 ms
W5	search batched (16 distinct dataset queries per request) closed loop	9.06 ms	10.13 ms	10.55 ms	11.31 ms	15.90 ms	24.54 ms	26.76 ms	27.79 ms	28.86 ms	29.30 ms
W6	quantized: scalar closed loop	663 µs	802 µs	867 µs	1.00 ms	2.07 ms	987 µs	1.23 ms	1.30 ms	1.43 ms	2.93 ms
W6-ef32	SQ8 recall control, ef=32 (latency only) closed loop	313 µs	497 µs	587 µs	705 µs	1.27 ms	454 µs	552 µs	617 µs	715 µs	1.76 ms
W6-ef64	SQ8 recall control, ef=64 (latency only) closed loop	458 µs	623 µs	826 µs	981 µs	1.52 ms	642 µs	776 µs	842 µs	998 µs	2.62 ms
W6-ef128	SQ8 recall control, ef=128 (latency only) closed loop	665 µs	803 µs	866 µs	984 µs	2.07 ms	991 µs	1.23 ms	1.30 ms	1.43 ms	2.93 ms
W6-ef256	SQ8 recall control, ef=256 (latency only) closed loop	1.09 ms	1.34 ms	1.41 ms	1.56 ms	3.11 ms	1.71 ms	2.20 ms	2.31 ms	2.45 ms	4.43 ms
W6-ef512	SQ8 recall control, ef=512 (latency only) closed loop	1.88 ms	2.36 ms	2.48 ms	2.63 ms	4.96 ms	2.95 ms	3.86 ms	4.06 ms	4.25 ms	6.84 ms
W7	quantized: binary + oversampling closed loop	459 µs	611 µs	670 µs	767 µs	1.28 ms	558 µs	628 µs	671 µs	777 µs	1.91 ms
W8	quantized: PQ closed loop	1.36 ms	1.64 ms	1.77 ms	1.99 ms	2.49 ms	1.81 ms	2.15 ms	2.32 ms	2.60 ms	3.94 ms
W9	exact / brute force closed loop	575.52 ms	1159.76 ms	1504.90 ms	2481.43 ms	3291.95 ms	808.83 ms	856.44 ms	871.60 ms	886.78 ms	890.70 ms
W10-ef32	recall control, ef=32 (latency only) closed loop	737 µs	1.02 ms	1.20 ms	1.67 ms	5.82 ms	1.00 ms	1.70 ms	1.98 ms	2.54 ms	6.33 ms
W10-ef64	recall control, ef=64 (latency only) closed loop	1.23 ms	1.67 ms	1.92 ms	2.39 ms	7.25 ms	1.54 ms	2.54 ms	3.02 ms	3.73 ms	7.85 ms
W10-ef128	recall control, ef=128 (latency only) closed loop	2.11 ms	2.89 ms	3.27 ms	3.76 ms	9.74 ms	2.52 ms	3.93 ms	4.63 ms	5.69 ms	8.31 ms
W10-ef256	recall control, ef=256 (latency only) closed loop	3.66 ms	5.14 ms	5.78 ms	6.60 ms	11.65 ms	4.23 ms	6.30 ms	7.42 ms	8.94 ms	12.10 ms
W10-ef512	recall control, ef=512 (latency only) closed loop	6.44 ms	9.18 ms	10.35 ms	11.85 ms	18.28 ms	7.39 ms	10.78 ms	12.24 ms	14.06 ms	17.58 ms
W12-sel1	filtered search, one keyword (~1% of bench12) closed loop	1.06 ms	1.11 ms	1.13 ms	1.19 ms	2.89 ms	1.24 ms	1.38 ms	1.44 ms	1.51 ms	3.52 ms
W12-sel10	filtered search, any of 10 keywords (~10% of bench12) closed loop	2.49 ms	2.89 ms	3.03 ms	3.21 ms	4.27 ms	2.44 ms	2.68 ms	2.78 ms	2.94 ms	5.10 ms
W12-sel1-ef32	filtered recall control, one keyword, ef=32 (latency only) closed loop	1.07 ms	1.11 ms	1.13 ms	1.18 ms	2.97 ms	585 µs	651 µs	687 µs	752 µs	2.05 ms
W12-sel1-ef64	filtered recall control, one keyword, ef=64 (latency only) closed loop	1.07 ms	1.11 ms	1.13 ms	1.19 ms	2.81 ms	826 µs	917 µs	956 µs	1.02 ms	2.68 ms
W12-sel1-ef128	filtered recall control, one keyword, ef=128 (latency only) closed loop	1.07 ms	1.11 ms	1.13 ms	1.17 ms	2.84 ms	1.22 ms	1.36 ms	1.41 ms	1.49 ms	3.41 ms
W12-sel1-ef256	filtered recall control, one keyword, ef=256 (latency only) closed loop	1.07 ms	1.11 ms	1.13 ms	1.17 ms	2.85 ms	1.85 ms	2.02 ms	2.09 ms	2.19 ms	4.36 ms
W12-sel1-ef512	filtered recall control, one keyword, ef=512 (latency only) closed loop	1.07 ms	1.11 ms	1.13 ms	1.17 ms	2.92 ms	2.63 ms	2.81 ms	2.88 ms	3.17 ms	5.45 ms
W12-sel10-ef32	filtered recall control, any of 10 keywords, ef=32 (latency only) closed loop	1.02 ms	1.19 ms	1.32 ms	1.56 ms	2.31 ms	872 µs	1.04 ms	1.14 ms	1.30 ms	2.80 ms
W12-sel10-ef64	filtered recall control, any of 10 keywords, ef=64 (latency only) closed loop	1.55 ms	1.79 ms	1.90 ms	2.16 ms	3.02 ms	1.42 ms	1.62 ms	1.73 ms	1.89 ms	3.71 ms
W12-sel10-ef128	filtered recall control, any of 10 keywords, ef=128 (latency only) closed loop	2.49 ms	2.89 ms	3.03 ms	3.22 ms	4.27 ms	2.44 ms	2.68 ms	2.79 ms	2.93 ms	5.13 ms
W12-sel10-ef256	filtered recall control, any of 10 keywords, ef=256 (latency only) closed loop	4.23 ms	4.98 ms	5.27 ms	5.55 ms	6.05 ms	4.13 ms	4.57 ms	4.75 ms	5.11 ms	8.01 ms
W12-sel10-ef512	filtered recall control, any of 10 keywords, ef=512 (latency only) closed loop	6.81 ms	7.30 ms	7.56 ms	7.85 ms	11.51 ms	6.99 ms	7.83 ms	8.12 ms	8.46 ms	10.79 ms
W13	scroll / pagination closed loop	137 µs	203 µs	230 µs	267 µs	1.11 ms	157 µs	219 µs	293 µs	446 µs	1.44 ms
W11-steady	mixed read/write below the rebuild threshold: search bench2 while 49,500 synthetic points append closed loop	9.02 ms	26.38 ms	34.05 ms	114.14 ms	158.21 ms	31.01 ms	56.46 ms	68.87 ms	82.97 ms	107.60 ms
W11	mixed read/write: search bench2 while 198,000 synthetic points append (runs last) closed loop	21.89 ms	91.16 ms	113.84 ms	140.08 ms	163.20 ms	70.85 ms	152.35 ms	186.56 ms	1871.42 ms	1927.46 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	35.5 GiBbefore W11-steady, W11	26.5 GiBbefore W11-steady, W11
peak RSS	35.1 GiB31.6 GiB before the writers	43.6 GiB
of which anonymous	4.0 GiB	3.4 GiB
of which file-backed	28.8 GiB	34.9 GiB
disk read bytes	86.0 MiB	1.2 GiB
disk write bytes	30.9 GiB	155.5 GiB
disk read ops	66,018	31,170
disk write ops	940,628	2,647,978
syscall reads (all fds)	10,524,703	27,131
syscall writes (all fds)	4,599,045	21,040,444

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	60.5 MiB	0	977	113.7 MiB	381.0 MiB	3,366	8,768
W0	0	0	0	3	0	0	0	6
W1	0	5.7 GiB	0	11,615	5.3 MiB	16.1 GiB	357	267,470
W2	0	5.7 GiB	0	93,568	172.4 MiB	25.6 GiB	4,374	441,697
W3	0	0	0	3	0	0	0	0
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	188.0 KiB	5.7 GiB	141	93,552	187.3 MiB	30.6 GiB	4,860	517,738
W6	0	0	0	3	0	0	0	0
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	20.0 KiB	5.7 GiB	15	94,166	229.2 MiB	30.8 GiB	6,264	527,400
W7	0	0	0	0	0	0	0	0
W8-upload	100.0 KiB	5.7 GiB	75	94,068	175.3 MiB	25.2 GiB	4,389	432,360
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	588.0 KiB	1.1 GiB	399	531,947	61.1 MiB	5.3 GiB	1,680	91,854
W12-sel1	0	0	0	3	0	0	0	219
W12-sel10	0	0	0	0	0	0	0	78
W12-sel1-ef32	0	0	0	0	0	0	0	0
W12-sel1-ef64	0	0	0	0	0	0	0	42
W12-sel1-ef128	0	0	0	0	0	0	0	60
W12-sel1-ef256	0	0	0	0	0	0	0	90
W12-sel1-ef512	0	0	0	0	0	0	0	54
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	71.8 MiB	290.0 MiB	55,116	5,200	161.2 MiB	12.5 GiB	3,951	213,470
W11	13.4 MiB	1.1 GiB	10,272	15,520	77.2 MiB	8.9 GiB	1,929	146,672

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	110.7 s	542%	48.2 ms	47,573 / 609	6	113,516 / 0	9 1%	165.4 s	520%	13,049.4 ms	161,670 / 28,463	12,323	412,973 / 210,113	40 7%
W0	7.7 s	70%	2.9 ms	163,573 / 37	0	0 / 0	9	14.8 s	103%	3.8 ms	556,507 / 14	126	416 / 0	37 0%
W1	11.6 s	139%	101.2 ms	607,984 / 27	0	1,576,446 / 0	9	251.2 s	701%	106,299.2 ms	158,301 / 89,633	33,511	666,356 / 1,598,650	52 55%
W2	2,025.5 s	769%	1,210.9 ms	611,814 / 9,113	4	1,640,250 / 0	9 1%	2,760.3 s	674%	117,360.9 ms	181,341 / 105,713	33,236	1,411,741 / 1,634,909	39 2%
W3	43.6 s	92%	9.6 ms	189,858 / 62	0	0 / 0	9	80.3 s	100%	6.1 ms	562,064 / 288	149	1,784 / 0	38 0%
W4	100.7 s	714%	7.0 ms	89,569 / 122	0	151 / 0	9	114.2 s	793%	97,543.2 ms	42,268 / 42,380	4,797	31,896 / 0	44 0%
W4-sat50	190.5 s	166%	14.3 ms	540,573 / 134	0	3 / 0	9	350.6 s	305%	12,370.5 ms	1,922,913 / 9,939	477,024	3,772 / 0	51 0%
W4-sat70	209.3 s	255%	15.0 ms	485,538 / 129	0	15 / 0	9	379.8 s	462%	75,709.2 ms	1,650,207 / 48,714	646,309	3,773 / 0	68
W4-sat90	278.8 s	436%	30.3 ms	440,967 / 215	0	15 / 0	9	417.1 s	652%	177,241.7 ms	881,633 / 162,106	340,555	14,126 / 0	44 0%
W5	100.3 s	708%	8.9 ms	6,898 / 178	0	0 / 0	9	75.9 s	198%	12.9 ms	38,987 / 463	1,289	2,618 / 0	42 0%
W6-upload	2,021.2 s	755%	1,145.2 ms	93,772 / 9,135	0	2,205,994 / 0	9 0%	1,196.3 s	562%	59,601.5 ms	219,218 / 59,050	32,442	2,573,002 / 1,681,028	41 1%
W6	29.6 s	179%	8.9 ms	182,905 / 54	0	0 / 0	9	50.2 s	203%	10.9 ms	539,698 / 168	17,550	961 / 0	44 0%
W6-ef32	13.4 s	161%	2.5 ms	172,962 / 6	0	0 / 0	9	23.4 s	204%	7.8 ms	513,951 / 64	11,899	98 / 0	44
W6-ef64	20.1 s	171%	2.1 ms	178,890 / 12	0	0 / 0	9	32.8 s	204%	7.2 ms	528,971 / 95	14,428	357 / 0	44
W6-ef128	29.7 s	179%	1.0 ms	181,877 / 18	0	0 / 0	9	50.4 s	203%	11.7 ms	540,542 / 160	18,237	584 / 0	44
W6-ef256	50.8 s	187%	5.9 ms	183,390 / 45	0	4 / 0	9	86.9 s	202%	36.9 ms	548,858 / 347	19,852	1,194 / 0	44
W6-ef512	90.5 s	192%	4.6 ms	186,213 / 168	0	3 / 0	9	148.8 s	201%	74.8 ms	556,185 / 674	20,010	1,936 / 0	44
W7-upload	2,004.4 s	730%	1,253.2 ms	99,475 / 9,394	2	1,698,226 / 293	9 0%	572.4 s	418%	53,138.7 ms	236,704 / 48,296	30,445	2,167,504 / 1,809,287	42 0%
W7	20.5 s	171%	2.2 ms	181,601 / 18	0	0 / 0	9	28.5 s	204%	9.3 ms	518,417 / 58	12,207	841 / 0	46 0%
W8-upload	2,850.9 s	774%	1,379.9 ms	107,375 / 13,108	14	1,869,849 / 0	9 0%	6,057.1 s	668%	30,852.7 ms	780,697 / 165,094	102,073	1,618,645 / 1,609,636	44 1%
W8	63.9 s	189%	7.6 ms	186,591 / 75	0	0 / 0	9	91.4 s	202%	79.2 ms	542,438 / 362	20,244	4,419 / 0	48 0%
W9	643.8 s	420%	102.3 ms	4,276,720 / 1,234	0	0 / 0	9	1,624.8 s	798%	13,447.9 ms	26,815 / 23,021	6,409	1,478 / 0	50
W10-ef32	32.5 s	685%	3.8 ms	98,381 / 44	0	0 / 0	9	40.4 s	591%	15,065.5 ms	247,706 / 24,603	84,121	1,261 / 0	50
W10-ef64	54.5 s	701%	5.4 ms	102,070 / 64	0	0 / 0	9	65.3 s	633%	38,874.7 ms	304,258 / 42,316	155,076	1,194 / 0	67 0%
W10-ef128	93.4 s	707%	8.8 ms	107,113 / 122	0	0 / 0	9	107.3 s	659%	58,175.7 ms	336,821 / 55,410	178,808	647 / 0	67
W10-ef256	162.2 s	706%	15.2 ms	113,067 / 257	0	0 / 0	9	186.5 s	690%	81,122.1 ms	368,784 / 82,953	193,845	664 / 0	67
W10-ef512	285.5 s	704%	25.5 ms	116,016 / 512	0	3 / 0	9	335.4 s	716%	110,818.9 ms	399,633 / 119,190	195,531	1,846 / 0	67
W12-upload	297.7 s	650%	166.6 ms	25,385 / 1,468	0	445,699 / 34	9 1%	520.5 s	528%	10,982.4 ms	67,814 / 12,405	7,863	372,899 / 446,815	51 0%
W12-sel1	49.5 s	185%	4.5 ms	126,934 / 41	0	0 / 0	9	62.7 s	202%	21.6 ms	533,653 / 149	17,479	1,065 / 0	56
W12-sel10	118.1 s	194%	6.9 ms	184,898 / 303	0	0 / 0	9	122.3 s	201%	131.2 ms	538,093 / 374	19,113	997 / 0	56
W12-sel1-ef32	49.5 s	184%	1.1 ms	125,326 / 26	0	0 / 0	9	29.8 s	202%	11.6 ms	511,180 / 38	10,549	304 / 0	56
W12-sel1-ef64	49.4 s	184%	1.7 ms	120,799 / 31	0	0 / 0	9	42.0 s	202%	10.9 ms	526,563 / 79	13,463	309 / 0	56
W12-sel1-ef128	49.5 s	184%	1.4 ms	121,877 / 30	0	0 / 0	9	61.8 s	202%	19.6 ms	535,564 / 221	17,422	581 / 0	56
W12-sel1-ef256	49.5 s	184%	1.1 ms	126,169 / 30	0	0 / 0	9	93.2 s	202%	118.2 ms	525,768 / 361	18,434	723 / 0	56
W12-sel1-ef512	49.4 s	184%	1.9 ms	129,987 / 37	0	0 / 0	9	131.4 s	199%	226.9 ms	513,873 / 655	16,525	1,210 / 0	56
W12-sel10-ef32	47.0 s	185%	7.4 ms	178,512 / 36	0	0 / 0	9	44.9 s	202%	10.7 ms	534,379 / 145	15,993	652 / 0	56
W12-sel10-ef64	72.6 s	190%	10.3 ms	181,617 / 83	0	0 / 0	9	72.3 s	202%	38.0 ms	538,686 / 318	19,122	736 / 0	56
W12-sel10-ef128	118.0 s	194%	10.3 ms	185,057 / 282	0	0 / 0	9	122.5 s	201%	154.7 ms	538,246 / 552	19,663	1,051 / 0	56
W12-sel10-ef256	201.5 s	193%	17.9 ms	172,673 / 637	0	0 / 0	9	205.8 s	200%	163.6 ms	562,966 / 1,614	22,176	2,134 / 0	56
W12-sel10-ef512	325.0 s	191%	38.1 ms	125,238 / 1,169	0	0 / 0	9	348.9 s	200%	140.4 ms	570,358 / 2,428	23,563	4,057 / 0	56
W13	5.6 s	138%	4.2 ms	242,724 / 13	0	0 / 0	9	9.1 s	413%	853.7 ms	381,104 / 4,420	108,063	780 / 0	66
W11-steady	351.5 s	781%	263,490.0 ms	80,207 / 116,101	1,118	580,619 / 91,221	9 48%	900.4 s	787%	784,454.5 ms	244,381 / 282,244	58,423	889,903 / 147,520	59 0%
W11	476.4 s	1,503%	208,739.9 ms	28,280 / 81,733	806	1,020,754 / 298,410	18 27%	652.0 s	813%	518,000.9 ms	124,645 / 177,338	25,478	769,832 / 324,970	66 85%

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.

Time stalled on memory

Time every task in the engine's cgroup was stalled on memory. Lower is better. 40 rows never stalled on memory 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	48.2 ms	0 ms	14 / 10 ms	1 / 1 ms	0 / 0 ms	13,049.4 ms	0 ms	1,202 / 18 ms	69 / 66 ms	0 / 0 ms
W0	2.9 ms	0 ms	47 / 47 ms	0 / 0 ms	0 / 0 ms	3.8 ms	0 ms	78 / 78 ms	0 / 0 ms	0 / 0 ms
W1	101.2 ms	0 ms	55 / 55 ms	2 / 2 ms	0 / 0 ms	106,299.2 ms	0 ms	9,340 / 29 ms	859 / 329 ms	0 / 0 ms
W2	1,210.9 ms	0 ms	190 / 74 ms	1 / 1 ms	0 / 0 ms	117,360.9 ms	0 ms	10,277 / 79 ms	4,954 / 4,332 ms	0 / 0 ms
W3	9.6 ms	0 ms	40 / 40 ms	0 / 0 ms	0 / 0 ms	6.1 ms	0 ms	108 / 107 ms	0 / 0 ms	0 / 0 ms
W4	7.0 ms	0 ms	3 / 3 ms	0 / 0 ms	0 / 0 ms	97,543.2 ms	0 ms	5,034 / 2 ms	0 / 0 ms	0 / 0 ms
W4-sat50	14.3 ms	0 ms	156 / 156 ms	0 / 0 ms	0 / 0 ms	12,370.5 ms	0 ms	1,728 / 270 ms	0 / 0 ms	0 / 0 ms
W4-sat70	15.0 ms	0 ms	156 / 156 ms	0 / 0 ms	0 / 0 ms	75,709.2 ms	0 ms	8,347 / 206 ms	0 / 0 ms	0 / 0 ms
W4-sat90	30.3 ms	0 ms	139 / 139 ms	0 / 0 ms	0 / 0 ms	177,241.7 ms	0 ms	16,413 / 93 ms	0 / 0 ms	0 / 0 ms
W5	8.9 ms	0 ms	2 / 2 ms	0 / 0 ms	0 / 0 ms	12.9 ms	0 ms	15 / 15 ms	0 / 0 ms	0 / 0 ms
W6-upload	1,145.2 ms	0 ms	156 / 44 ms	13 / 13 ms	0 / 0 ms	59,601.5 ms	0 ms	5,586 / 77 ms	10,395 / 9,918 ms	0 / 0 ms
W6	8.9 ms	0 ms	36 / 36 ms	0 / 0 ms	0 / 0 ms	10.9 ms	0 ms	67 / 66 ms	0 / 0 ms	0 / 0 ms
W6-ef32	2.5 ms	0 ms	31 / 31 ms	0 / 0 ms	0 / 0 ms	7.8 ms	0 ms	55 / 54 ms	0 / 0 ms	0 / 0 ms
W6-ef64	2.1 ms	0 ms	38 / 38 ms	0 / 0 ms	0 / 0 ms	7.2 ms	0 ms	60 / 59 ms	0 / 0 ms	0 / 0 ms
W6-ef128	1.0 ms	0 ms	36 / 36 ms	0 / 0 ms	0 / 0 ms	11.7 ms	0 ms	68 / 67 ms	0 / 0 ms	0 / 0 ms
W6-ef256	5.9 ms	0 ms	37 / 37 ms	0 / 0 ms	0 / 0 ms	36.9 ms	0 ms	116 / 113 ms	0 / 0 ms	0 / 0 ms
W6-ef512	4.6 ms	0 ms	37 / 37 ms	0 / 0 ms	0 / 0 ms	74.8 ms	0 ms	148 / 142 ms	0 / 0 ms	0 / 0 ms
W7-upload	1,253.2 ms	0 ms	184 / 55 ms	42 / 42 ms	563 / 563 ms	53,138.7 ms	0 ms	4,999 / 88 ms	9,288 / 7,514 ms	0 / 0 ms
W7	2.2 ms	0 ms	34 / 34 ms	0 / 0 ms	0 / 0 ms	9.3 ms	0 ms	57 / 57 ms	0 / 0 ms	0 / 0 ms
W8-upload	1,379.9 ms	0 ms	189 / 48 ms	62 / 62 ms	84 / 84 ms	30,852.7 ms	0 ms	7,227 / 298 ms	3,991 / 2,329 ms	0 / 0 ms
W8	7.6 ms	0 ms	37 / 37 ms	0 / 0 ms	0 / 0 ms	79.2 ms	0 ms	120 / 111 ms	0 / 0 ms	0 / 0 ms
W9	102.3 ms	0 ms	505 / 505 ms	0 / 0 ms	0 / 0 ms	13,447.9 ms	0 ms	1,617 / 38 ms	0 / 0 ms	0 / 0 ms
W10-ef32	3.8 ms	0 ms	10 / 10 ms	0 / 0 ms	0 / 0 ms	15,065.5 ms	0 ms	1,768 / 23 ms	0 / 0 ms	0 / 0 ms
W10-ef64	5.4 ms	0 ms	9 / 9 ms	0 / 0 ms	0 / 0 ms	38,874.7 ms	0 ms	3,754 / 23 ms	0 / 0 ms	0 / 0 ms
W10-ef128	8.8 ms	0 ms	9 / 9 ms	0 / 0 ms	0 / 0 ms	58,175.7 ms	0 ms	5,650 / 34 ms	0 / 0 ms	0 / 0 ms
W10-ef256	15.2 ms	0 ms	8 / 8 ms	0 / 0 ms	0 / 0 ms	81,122.1 ms	0 ms	8,322 / 35 ms	0 / 0 ms	0 / 0 ms
W10-ef512	25.5 ms	0 ms	7 / 7 ms	0 / 0 ms	0 / 0 ms	110,818.9 ms	0 ms	11,792 / 64 ms	0 / 0 ms	0 / 0 ms
W12-upload	166.6 ms	0 ms	25 / 9 ms	54 / 54 ms	2,219 / 2,219 ms	10,982.4 ms	0 ms	1,054 / 29 ms	266 / 171 ms	0 / 0 ms
W12-sel1	4.5 ms	0 ms	35 / 35 ms	0 / 0 ms	0 / 0 ms	21.6 ms	0 ms	78 / 76 ms	0 / 0 ms	0 / 0 ms
W12-sel10	6.9 ms	0 ms	37 / 37 ms	0 / 0 ms	0 / 0 ms	131.2 ms	0 ms	143 / 128 ms	0 / 0 ms	0 / 0 ms
W12-sel1-ef32	1.1 ms	0 ms	35 / 35 ms	0 / 0 ms	0 / 0 ms	11.6 ms	0 ms	58 / 57 ms	0 / 0 ms	0 / 0 ms
W12-sel1-ef64	1.7 ms	0 ms	35 / 35 ms	0 / 0 ms	0 / 0 ms	10.9 ms	0 ms	63 / 62 ms	0 / 0 ms	0 / 0 ms
W12-sel1-ef128	1.4 ms	0 ms	35 / 35 ms	0 / 0 ms	0 / 0 ms	19.6 ms	0 ms	76 / 75 ms	0 / 0 ms	0 / 0 ms
W12-sel1-ef256	1.1 ms	0 ms	35 / 35 ms	0 / 0 ms	0 / 0 ms	118.2 ms	0 ms	125 / 111 ms	0 / 0 ms	0 / 0 ms
W12-sel1-ef512	1.9 ms	0 ms	35 / 35 ms	0 / 0 ms	0 / 0 ms	226.9 ms	0 ms	145 / 122 ms	0 / 0 ms	0 / 0 ms
W12-sel10-ef32	7.4 ms	0 ms	36 / 36 ms	0 / 0 ms	0 / 0 ms	10.7 ms	0 ms	65 / 64 ms	0 / 0 ms	0 / 0 ms
W12-sel10-ef64	10.3 ms	0 ms	36 / 36 ms	0 / 0 ms	0 / 0 ms	38.0 ms	0 ms	94 / 90 ms	0 / 0 ms	0 / 0 ms
W12-sel10-ef128	10.3 ms	0 ms	38 / 38 ms	0 / 0 ms	0 / 0 ms	154.7 ms	0 ms	147 / 129 ms	0 / 0 ms	0 / 0 ms
W12-sel10-ef256	17.9 ms	0 ms	41 / 41 ms	0 / 0 ms	0 / 0 ms	163.6 ms	0 ms	166 / 152 ms	0 / 0 ms	0 / 0 ms
W12-sel10-ef512	38.1 ms	0 ms	42 / 42 ms	0 / 0 ms	0 / 0 ms	140.4 ms	0 ms	202 / 191 ms	0 / 0 ms	0 / 0 ms
W13	4.2 ms	0 ms	28 / 28 ms	0 / 0 ms	0 / 0 ms	853.7 ms	0 ms	121 / 26 ms	0 / 0 ms	0 / 0 ms
W11-steady	263,490.0 ms	0 ms	33,892 / 11 ms	490 / 90 ms	0 / 0 ms	784,454.5 ms	0 ms	85,464 / 64 ms	1,684 / 46 ms	0 / 0 ms
W11	208,739.9 ms	0 ms	26,851 / 13 ms	100 / 71 ms	0 / 0 ms	518,000.9 ms	0 ms	52,090 / 34 ms	1,886 / 131 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.50	2.001.004x nominal	5.36	-	-	-	1.30	2.001.004x nominal	4.53	-	-	-
W0	1.26	2.011.005x nominal	5.83	253,118	6.8 KiB	987.6	1.17	2.011.005x nominal	3.07	462,931	37.6 KiB	1,253.1
W1	2.01	2.011.005x nominal	0.69	-	-	-	1.10	2.011.005x nominal	1.23	-	-	-
W2	0.42	2.011.005x nominal	2.35	-	-	-	0.60	2.011.005x nominal	1.74	-	-	-
W3	0.71	2.011.006x nominal	3.84	1,673,908	5,795.5 KiB	4,265.8	0.68	2.011.005x nominal	1.93	3,070,597	4,539.1 KiB	6,973.2
W4	0.29	2.011.005x nominal	3.24	4,018,297	4,318.8 KiB	4,073.2	0.44	2.001.004x nominal	2.00	4,515,449	4,229.3 KiB	6,179.4
W4-sat50	0.64	2.011.006x nominal	3.86	1,852,636	5,434.5 KiB	4,209.3	0.61	2.011.005x nominal	2.18	3,399,202	4,503.4 KiB	6,939.2
W4-sat70	0.58	2.011.005x nominal	3.89	2,040,179	5,093.9 KiB	4,182.9	0.57	2.011.005x nominal	2.26	3,646,947	4,415.5 KiB	6,865.3
W4-sat90	0.44	2.011.005x nominal	3.76	2,718,387	4,460.7 KiB	4,161.3	0.50	2.011.006x nominal	2.23	4,096,739	4,312.2 KiB	6,567.0
W5	0.28	2.011.005x nominal	3.45	4,012,854	4,352.8 KiB	4,013.3	0.60	2.011.005x nominal	2.18	3,021,595	4,680.5 KiB	5,890.6
W6-upload	0.42	2.011.005x nominal	2.28	-	-	-	1.68	2.011.005x nominal	1.48	-	-	-
W6	0.89	2.011.006x nominal	4.96	1,119,117	3,024.8 KiB	6,182.6	1.50	2.011.006x nominal	1.61	1,881,039	747.9 KiB	4,767.7
W6-ef32	0.87	2.001.004x nominal	3.57	480,384	956.7 KiB	2,390.1	1.60	2.011.007x nominal	1.27	818,939	242.0 KiB	2,165.5
W6-ef64	0.84	2.011.006x nominal	4.41	735,259	1,678.6 KiB	3,768.9	1.55	2.011.006x nominal	1.44	1,189,321	417.7 KiB	3,102.5
W6-ef128	0.89	2.011.006x nominal	4.99	1,120,582	3,027.8 KiB	6,191.4	1.49	2.011.006x nominal	1.65	1,888,084	746.6 KiB	4,802.1
W6-ef256	0.88	2.011.006x nominal	5.48	1,965,684	5,423.8 KiB	11,026.4	1.39	2.011.005x nominal	2.00	3,299,760	1,439.3 KiB	7,732.8
W6-ef512	0.88	2.011.006x nominal	5.93	3,558,528	9,787.3 KiB	21,026.7	1.36	2.011.006x nominal	2.13	5,749,620	2,682.8 KiB	12,895.3
W7-upload	0.42	2.011.005x nominal	2.76	-	-	-	2.04	2.001.004x nominal	4.72	-	-	-
W7	1.08	2.011.005x nominal	7.99	762,362	447.3 KiB	3,505.1	1.66	2.011.005x nominal	3.21	1,018,381	350.6 KiB	3,853.2
W8-upload	2.41	2.011.005x nominal	0.73	-	-	-	5.40	2.001.004x nominal	0.17	-	-	-
W8	4.07	2.011.006x nominal	0.59	2,489,262	469.4 KiB	4,458.3	2.95	2.011.006x nominal	0.62	3,483,686	508.3 KiB	5,167.2
W9	0.62	2.001.004x nominal	0.33	621,894,169	752,253.1 KiB	1,472,011.8	0.36	2.011.005x nominal	0.09	1,627,503,846	525,904.2 KiB	1,421,558.3
W10-ef32	0.37	2.011.005x nominal	2.41	1,281,237	1,354.1 KiB	2,268.7	0.63	2.011.005x nominal	1.95	1,538,453	1,527.7 KiB	2,637.3
W10-ef64	0.34	2.011.005x nominal	2.93	2,161,472	2,314.8 KiB	3,741.6	0.56	2.011.005x nominal	2.14	2,478,103	2,541.6 KiB	4,045.6
W10-ef128	0.32	2.011.005x nominal	3.31	3,716,024	4,011.3 KiB	6,516.4	0.51	2.001.004x nominal	2.33	4,114,718	4,308.2 KiB	6,472.2
W10-ef256	0.31	2.011.005x nominal	3.63	6,475,355	6,999.6 KiB	11,791.5	0.47	2.001.004x nominal	2.46	7,237,923	7,521.7 KiB	10,654.9
W10-ef512	0.32	2.011.005x nominal	4.00	11,425,813	12,417.5 KiB	21,944.0	0.43	2.001.004x nominal	2.80	13,132,738	13,522.6 KiB	18,055.8
W12-upload	0.50	2.011.005x nominal	2.46	-	-	-	0.85	2.011.005x nominal	1.98	-	-	-
W12-sel1	0.50	2.011.005x nominal	2.92	1,927,738	7,189.7 KiB	4,611.6	0.84	2.001.004x nominal	3.14	2,364,769	2,530.8 KiB	4,490.1
W12-sel10	1.02	2.011.005x nominal	3.96	4,660,212	9,143.5 KiB	10,406.0	0.82	2.011.005x nominal	2.31	4,702,400	5,188.2 KiB	7,838.2
W12-sel1-ef32	0.50	2.011.005x nominal	2.91	1,926,645	7,193.4 KiB	4,615.2	0.94	2.011.005x nominal	2.18	1,076,378	1,080.2 KiB	2,432.0
W12-sel1-ef64	0.50	2.011.005x nominal	2.93	1,927,427	7,195.5 KiB	4,617.0	0.89	2.011.005x nominal	2.55	1,558,731	1,667.3 KiB	3,318.2
W12-sel1-ef128	0.50	2.011.005x nominal	2.95	1,926,338	7,195.6 KiB	4,615.3	0.85	2.011.006x nominal	3.10	2,339,876	2,512.8 KiB	4,491.9
W12-sel1-ef256	0.50	2.011.006x nominal	2.93	1,929,668	7,193.5 KiB	4,611.3	0.83	2.011.005x nominal	3.83	3,552,056	3,599.0 KiB	5,763.9
W12-sel1-ef512	0.50	2.011.006x nominal	2.92	1,929,437	7,189.5 KiB	4,616.9	0.89	2.011.006x nominal	4.16	5,083,385	4,653.3 KiB	7,000.2
W12-sel10-ef32	0.99	2.011.006x nominal	3.24	1,819,219	3,365.4 KiB	3,875.1	0.95	2.011.005x nominal	1.78	1,667,659	1,688.1 KiB	3,336.8
W12-sel10-ef64	0.99	2.011.005x nominal	3.67	2,841,106	5,584.0 KiB	6,118.5	0.86	2.011.005x nominal	2.08	2,733,704	2,933.6 KiB	4,987.1
W12-sel10-ef128	1.02	2.011.006x nominal	3.97	4,664,692	9,152.2 KiB	10,396.9	0.82	2.011.005x nominal	2.31	4,703,626	5,187.6 KiB	7,847.4
W12-sel10-ef256	1.05	2.011.006x nominal	4.18	8,001,698	14,867.8 KiB	18,748.6	0.82	2.011.005x nominal	2.38	8,011,930	8,876.0 KiB	12,544.3
W12-sel10-ef512	0.60	2.011.005x nominal	0.77	12,956,693	41,598.7 KiB	33,839.1	0.83	2.001.004x nominal	2.53	13,720,887	14,608.6 KiB	19,692.4
W13	1.36	2.011.007x nominal	1.20	42,284	1.0 KiB	12.7	1.47	2.011.006x nominal	1.41	137,352	1.4 KiB	40.0
W11-steady	0.33	2.001.005x nominal	1.87	22,322,253	26,845.9 KiB	29,355.2	0.52	2.011.005x nominal	0.56	57,372,418	27,374.6 KiB	56,061.9
W11	0.37	2.001.005x nominal	1.64	119,356,527	157,005.0 KiB	155,746.3	0.57	2.011.005x nominal	0.53	162,278,418	83,060.1 KiB	159,785.1

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. strawmANN: perf and /proc disagree on minor faults by up to 13% on W12-upload; strawmANN: perf and /proc disagree on context switches by up to 9% on W11-steady, W11; Qdrant: perf and /proc disagree on minor faults by up to 43% on W1, W2, W6-upload, W7-upload, W8-upload, W12-upload, W11-steady, W11; Qdrant: perf and /proc disagree on context switches by up to 65% on 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	990,000	990,000	4	16	100	-	1	cached
bench1	1 / 5	- / 5	- / 1	990,000	0 / 57,200	1,536	16	100	-	1	cached
bench2	1 / 2	- / 1	- / 1	990,000	990,000	1,536	16	100	-	1	cached
bench6	1 / 2	- / 1	- / 1	990,000	990,000	1,536	16	100	scalar	1	cached
bench7	1 / 2	- / 1	- / 1	990,000	990,000	1,536	16	100	binary	1	cached
bench8	1 / 2	- / 1	- / 1	990,000	990,000	1,536	16	100	product	1	cached
bench12	1 / 2	- / 1	- / 1	200,000	200,000	1,536	16	100	-	1	cached

After the mutating rows bench2 held strawmANN 1,237,500 (+247,500), 1,137,262 of them indexed; Qdrant 1,237,500 (+247,500), 1,040,500 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=990,000

metric	strawmANN	Qdrant
wall clock	20.4 s	31.8 s	1.56x
of which upload	1.3 s	7.5 s	5.80x
of which index wait	17.1 s	22.1 s	1.29x
time to Green	17.1 s	22.1 s	1.29x
cpu	110.7 s	165.4 s	1.49x
cpu, % of wall	542%	520%
waiting for a core	48.2 ms	13,049.4 ms	270.66x
migrations	6	12,323	2,053.83x
faults min/maj	113,516 / 0	412,973 / 210,113
peak RSS	440.5 MiB	1.6 GiB	3.65x
disk written	60.5 MiB	381.0 MiB
disk read	0	113.7 MiB

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

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

metric	strawmANN	Qdrant
queries/second	4,598	3,495	1.32x
client p50	213 µs	285 µs	1.34x
client p99	261 µs	348 µs	1.34x
client p99.9	305 µs	400 µs	1.31x
server p50	121 µs	182 µs	1.50x
server p99	133 µs	218 µs	1.65x
wall clock	10.9 s	14.3 s	1.31x
queries sent	50,000	50,000
cpu	7.7 s	14.8 s	1.92x
cpu, % of wall	70%	103%
waiting for a core	2.9 ms	3.8 ms	1.30x
migrations	0	126
faults min/maj	0 / 0	416 / 0
peak RSS	440.5 MiB	1.6 GiB	3.65x
disk written	0	0
disk read	0	0

1.32x is 1.83x less work per query x 0.67x cores busy during the row (0.67 against 1.01) x 1.00x clock x 1.08x 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=990,000

metric	strawmANN	Qdrant
wall clock	8.4 s	35.8 s	4.26x
of which upload	5.5 s	33.6 s	6.07x
cpu	11.6 s	251.2 s	21.58x
cpu, % of wall	139%	701%
waiting for a core	101.2 ms	106,299.2 ms	1,050.45x
migrations	0	33,511
faults min/maj	1,576,446 / 0	666,356 / 1,598,650
peak RSS	7.6 GiB	12.3 GiB	1.61x
disk written	5.7 GiB	16.1 GiB
disk read	0	5.3 MiB

W2 index build time

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

metric	strawmANN	Qdrant
wall clock	263.2 s	409.6 s	1.56x
of which upload	5.5 s	35.8 s	6.49x
of which index wait	254.9 s	370.9 s	1.46x
time to Green	254.9 s	370.9 s	1.46x
cpu	2,025.5 s	2,760.3 s	1.36x
cpu, % of wall	769%	674%
waiting for a core	1,210.9 ms	117,360.9 ms	96.92x
migrations	4	33,236	8,309.00x
faults min/maj	1,640,250 / 0	1,411,741 / 1,634,909
peak RSS	7.9 GiB	18.1 GiB	2.30x
disk written	5.7 GiB	25.6 GiB
disk read	0	172.4 MiB

W3 search, fp32, single query 1.70x

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,060	624	1.70x
recall@10	0.9667	0.9694	~equal
client p50	947 µs	1.60 ms	1.69x
client p99	1.37 ms	2.29 ms	1.67x
client p99.9	1.89 ms	2.57 ms	1.36x
server p50	845 µs	1.47 ms	1.74x
server p99	1.26 ms	2.15 ms	1.71x
wall clock	47.2 s	80.2 s	1.70x
queries sent	50,000	50,000
cpu	43.6 s	80.3 s	1.84x
cpu, % of wall	92%	100%
waiting for a core	9.6 ms	6.1 ms	0.63x
migrations	0	149
faults min/maj	0 / 0	1,784 / 0
peak RSS	7.9 GiB	18.1 GiB	2.30x
disk written	0	0
disk read	0	0

W4 search, saturating (closed loop) 1.02x

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

metric	strawmANN	Qdrant
queries/second	3,556	3,483	~equal
recall@10	0.9667	0.9694	~equal
client p50	18.05 ms	18.14 ms	~equal
client p99	20.22 ms	32.49 ms	1.61x
client p99.9	26.83 ms	43.64 ms	1.63x
server p50	17.93 ms	17.64 ms	~equal
server p99	20.07 ms	27.56 ms	1.37x
wall clock	14.1 s	14.4 s	1.02x
queries sent	50,000	50,000
cpu	100.7 s	114.2 s	1.13x
cpu, % of wall	714%	793%
waiting for a core	7.0 ms	97,543.2 ms	13,948.10x
migrations	0	4,797
faults min/maj	151 / 0	31,896 / 0
peak RSS	7.9 GiB	18.1 GiB	2.30x
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=1,741/s (50% of saturation, pinned reference 3,481 qps) · collection=bench2 · client -p n/a under --rps -t 16 -c 2 · n=200,000

metric	strawmANN	Qdrant
queries/second	1,741	1,741	offered
recall@10	0.9667	0.9694	~equal
client p50	1.03 ms	1.76 ms	1.72x
client p99	1.63 ms	2.95 ms	1.81x
client p99.9	1.87 ms	3.77 ms	2.01x
server p50	922 µs	1.61 ms	1.75x
server p99	1.52 ms	2.73 ms	1.79x
wall clock	115.0 s	115.0 s	~equal
queries sent	200,000	200,000
cpu	190.5 s	350.6 s	1.84x
cpu, % of wall	166%	305%
waiting for a core	14.3 ms	12,370.5 ms	868.04x
migrations	0	477,024
faults min/maj	3 / 0	3,772 / 0
peak RSS	7.9 GiB	18.1 GiB	2.30x
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=2,437/s (70% of saturation, pinned reference 3,481 qps) · collection=bench2 · client -p n/a under --rps -t 16 -c 2 · n=200,000

metric	strawmANN	Qdrant
queries/second	2,437	2,437	offered
recall@10	0.9667	0.9694	~equal
client p50	1.11 ms	2.00 ms	1.80x
client p99	1.95 ms	3.75 ms	1.93x
client p99.9	2.29 ms	4.76 ms	2.08x
server p50	1.01 ms	1.82 ms	1.81x
server p99	1.84 ms	3.45 ms	1.88x
wall clock	82.2 s	82.2 s	~equal
queries sent	200,000	200,000
cpu	209.3 s	379.8 s	1.81x
cpu, % of wall	255%	462%
waiting for a core	15.0 ms	75,709.2 ms	5,060.41x
migrations	0	646,309
faults min/maj	15 / 0	3,773 / 0
peak RSS	7.9 GiB	18.1 GiB	2.30x
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=3,133/s (90% of saturation, pinned reference 3,481 qps) · collection=bench2 · client -p n/a under --rps -t 16 -c 2 · n=200,000

metric	strawmANN	Qdrant
queries/second	3,133	3,133	offered
recall@10	0.9667	0.9694	~equal
client p50	1.39 ms	2.70 ms	1.94x
client p99	2.83 ms	9.53 ms	3.37x
client p99.9	3.56 ms	17.91 ms	5.03x
server p50	1.28 ms	2.38 ms	1.86x
server p99	2.70 ms	7.12 ms	2.64x
wall clock	64.0 s	64.0 s	~equal
queries sent	200,000	200,000
cpu	278.8 s	417.1 s	1.50x
cpu, % of wall	436%	652%
waiting for a core	30.3 ms	177,241.7 ms	5,847.05x
migrations	0	340,555
faults min/maj	15 / 0	14,126 / 0
peak RSS	7.9 GiB	18.1 GiB	2.30x
disk written	0	0
disk read	0	0

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

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	3,530	1,303	2.71x
recall@10	0.9667	0.9694	~equal
client p50	9.06 ms	24.54 ms	2.71x
client p99	10.55 ms	27.79 ms	2.63x
client p99.9	11.31 ms	28.86 ms	2.55x
server p50	8.41 ms	23.68 ms	2.81x
server p99	9.90 ms	26.88 ms	2.72x
wall clock	14.2 s	38.4 s	2.71x
queries sent	50,000	50,000
cpu	100.3 s	75.9 s	0.76x
cpu, % of wall	708%	198%
waiting for a core	8.9 ms	12.9 ms	1.44x
migrations	0	1,289
faults min/maj	0 / 0	2,618 / 0
peak RSS	7.9 GiB	18.1 GiB	2.30x
disk written	0	0
disk read	0	0

per-batch latency (16 queries/request); queries: dataset, random-sample 2.71x is 0.75x less work per query x 3.58x cores busy during the row (7.07 against 1.97) x 1.00x clock: 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=990,000

metric	strawmANN	Qdrant
wall clock	267.6 s	212.8 s	0.80x
of which upload	5.8 s	31.2 s	5.37x
of which index wait	258.9 s	176.4 s	0.68x
time to Green	258.9 s	176.4 s	0.68x
cpu	2,021.2 s	1,196.3 s	0.59x
cpu, % of wall	755%	562%
waiting for a core	1,145.2 ms	59,601.5 ms	52.04x
migrations	0	32,442
faults min/maj	2,205,994 / 0	2,573,002 / 1,681,028
peak RSS	17.4 GiB	32.3 GiB	1.86x
disk written	5.7 GiB	30.6 GiB
disk read	188.0 KiB	187.3 MiB

W6 quantized: scalar 1.50x

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,028	2,026	1.50x
recall@10	0.9669	0.9682	~equal
client p50	663 µs	987 µs	1.49x
client p99	867 µs	1.30 ms	1.50x
client p99.9	1.00 ms	1.43 ms	1.43x
server p50	568 µs	872 µs	1.54x
server p99	766 µs	1.18 ms	1.53x
wall clock	16.6 s	24.7 s	1.49x
queries sent	50,000	50,000
cpu	29.6 s	50.2 s	1.70x
cpu, % of wall	179%	203%
waiting for a core	8.9 ms	10.9 ms	1.22x
migrations	0	17,550
faults min/maj	0 / 0	961 / 0
peak RSS	17.4 GiB	32.3 GiB	1.86x
disk written	0	0
disk read	0	0

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

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	6,051	4,361	1.39x
recall@10	0.8918	0.8906	~equal
client p50	313 µs	454 µs	1.45x
client p99	587 µs	617 µs	1.05x
client p99.9	705 µs	715 µs	~equal
server p50	223 µs	347 µs	1.56x
server p99	475 µs	508 µs	1.07x
wall clock	8.3 s	11.5 s	1.39x
queries sent	50,000	50,000
cpu	13.4 s	23.4 s	1.75x
cpu, % of wall	161%	204%
waiting for a core	2.5 ms	7.8 ms	3.11x
migrations	0	11,899
faults min/maj	0 / 0	98 / 0
peak RSS	17.4 GiB	32.3 GiB	1.86x
disk written	0	0
disk read	0	0

1.39x is 1.70x less work per query x 0.79x cores busy during the row (1.59 against 2.02) x 1.00x clock x 1.04x counted on-CPU share: the middle term is occupancy, not search speed

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

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	4,266	3,109	1.37x
recall@10	0.9393	0.9413	~equal
client p50	458 µs	642 µs	1.40x
client p99	826 µs	842 µs	~equal
client p99.9	981 µs	998 µs	~equal
server p50	364 µs	531 µs	1.46x
server p99	712 µs	727 µs	1.02x
wall clock	11.8 s	16.1 s	1.37x
queries sent	50,000	50,000
cpu	20.1 s	32.8 s	1.64x
cpu, % of wall	171%	204%
waiting for a core	2.1 ms	7.2 ms	3.38x
migrations	0	14,428
faults min/maj	0 / 0	357 / 0
peak RSS	17.4 GiB	32.3 GiB	1.86x
disk written	0	0
disk read	0	0

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

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,022	2,018	1.50x
recall@10	0.9669	0.9682	~equal
client p50	665 µs	991 µs	1.49x
client p99	866 µs	1.30 ms	1.50x
client p99.9	984 µs	1.43 ms	1.46x
server p50	569 µs	875 µs	1.54x
server p99	766 µs	1.18 ms	1.54x
wall clock	16.6 s	24.8 s	1.50x
queries sent	50,000	50,000
cpu	29.7 s	50.4 s	1.70x
cpu, % of wall	179%	203%
waiting for a core	1.0 ms	11.7 ms	11.36x
migrations	0	18,237
faults min/maj	0 / 0	584 / 0
peak RSS	17.4 GiB	32.3 GiB	1.86x
disk written	0	0
disk read	0	0

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

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	1,841	1,164	1.58x
recall@10	0.9811	0.9820	~equal
client p50	1.09 ms	1.71 ms	1.57x
client p99	1.41 ms	2.31 ms	1.64x
client p99.9	1.56 ms	2.45 ms	1.57x
server p50	989 µs	1.58 ms	1.60x
server p99	1.31 ms	2.18 ms	1.66x
wall clock	27.2 s	43.0 s	1.58x
queries sent	50,000	50,000
cpu	50.8 s	86.9 s	1.71x
cpu, % of wall	187%	202%
waiting for a core	5.9 ms	36.9 ms	6.24x
migrations	0	19,852
faults min/maj	4 / 0	1,194 / 0
peak RSS	17.4 GiB	32.3 GiB	1.86x
disk written	0	0
disk read	0	0

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

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,063	674	1.58x
recall@10	0.9895	0.9900	~equal
client p50	1.88 ms	2.95 ms	1.57x
client p99	2.48 ms	4.06 ms	1.63x
client p99.9	2.63 ms	4.25 ms	1.62x
server p50	1.78 ms	2.80 ms	1.57x
server p99	2.38 ms	3.90 ms	1.64x
wall clock	47.1 s	74.2 s	1.58x
queries sent	50,000	50,000
cpu	90.5 s	148.8 s	1.64x
cpu, % of wall	192%	201%
waiting for a core	4.6 ms	74.8 ms	16.43x
migrations	0	20,010
faults min/maj	3 / 0	1,936 / 0
peak RSS	17.4 GiB	32.3 GiB	1.86x
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=990,000

metric	strawmANN	Qdrant
wall clock	274.7 s	136.9 s	0.50x
of which upload	5.9 s	45.4 s	7.66x
of which index wait	263.9 s	89.2 s	0.34x
time to Green	263.9 s	89.2 s	0.34x
cpu	2,004.4 s	572.4 s	0.29x
cpu, % of wall	730%	418%
waiting for a core	1,253.2 ms	53,138.7 ms	42.40x
migrations	2	30,445	15,222.50x
faults min/maj	1,698,226 / 293	2,167,504 / 1,809,287
peak RSS	23.6 GiB	37.1 GiB	1.57x
disk written	5.7 GiB	30.8 GiB
disk read	20.0 KiB	229.2 MiB

W7 quantized: binary + oversampling 1.16x

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,168	3,579	1.16x
recall@10	0.9470	0.9456	~equal
client p50	459 µs	558 µs	1.21x
client p99	670 µs	671 µs	~equal
client p99.9	767 µs	777 µs	~equal
server p50	364 µs	450 µs	1.23x
server p99	556 µs	553 µs	~equal
wall clock	12.0 s	14.0 s	1.16x
queries sent	50,000	50,000
cpu	20.5 s	28.5 s	1.39x
cpu, % of wall	171%	204%
waiting for a core	2.2 ms	9.3 ms	4.22x
migrations	0	12,207
faults min/maj	0 / 0	841 / 0
peak RSS	23.6 GiB	37.1 GiB	1.57x
disk written	0	0
disk read	0	0

W8-upload PQ: load

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

metric	strawmANN	Qdrant
wall clock	368.5 s	907.0 s	2.46x
of which upload	6.7 s	28.7 s	4.30x
of which index wait	359.3 s	875.1 s	2.44x
time to Green	359.3 s	875.1 s	2.44x
cpu	2,850.9 s	6,057.1 s	2.12x
cpu, % of wall	774%	668%
waiting for a core	1,379.9 ms	30,852.7 ms	22.36x
migrations	14	102,073	7,290.93x
faults min/maj	1,869,849 / 0	1,618,645 / 1,609,636
peak RSS	25.0 GiB	43.6 GiB	1.74x
disk written	5.7 GiB	25.2 GiB
disk read	100.0 KiB	175.3 MiB

W8 quantized: PQ 1.34x

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,482	1,106	1.34x
recall@10	0.9654	0.9644	~equal
client p50	1.36 ms	1.81 ms	1.33x
client p99	1.77 ms	2.32 ms	1.31x
client p99.9	1.99 ms	2.60 ms	1.30x
server p50	1.26 ms	1.68 ms	1.34x
server p99	1.66 ms	2.17 ms	1.31x
wall clock	33.8 s	45.3 s	1.34x
queries sent	50,000	50,000
cpu	63.9 s	91.4 s	1.43x
cpu, % of wall	189%	202%
waiting for a core	7.6 ms	79.2 ms	10.46x
migrations	0	20,244
faults min/maj	0 / 0	4,419 / 0
peak RSS	25.0 GiB	43.6 GiB	1.74x
disk written	0	0
disk read	0	0

W9 exact / brute force 1.33x

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

metric	strawmANN	Qdrant
queries/second	13	10	1.33x
client p50	575.52 ms	808.83 ms	1.41x
client p99	1,504.90 ms	871.60 ms	0.58x
client p99.9	2,481.43 ms	886.78 ms	0.36x
server p50	574.47 ms	807.41 ms	1.41x
server p99	1,504.22 ms	869.93 ms	0.58x
wall clock	153.1 s	203.6 s	1.33x
queries sent	2,000	2,000
cpu	643.8 s	1,624.8 s	2.52x
cpu, % of wall	420%	798%
waiting for a core	102.3 ms	13,447.9 ms	131.48x
migrations	0	6,409
faults min/maj	0 / 0	1,478 / 0
peak RSS	29.3 GiB	43.6 GiB	1.49x
disk written	0	0
disk read	0	0

1.33x is 2.62x less work per query x 0.53x cores busy during the row (4.20 against 7.98) x 1.00x clock x 0.97x counted on-CPU share: the middle term is occupancy, not search speed brute force over the whole collection, no index involved

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

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	10,625	7,358	1.44x
recall@10	0.8912	0.8945	~equal
client p50	737 µs	1.00 ms	1.36x
client p99	1.20 ms	1.98 ms	1.65x
client p99.9	1.67 ms	2.54 ms	1.52x
server p50	641 µs	816 µs	1.27x
server p99	1.11 ms	1.72 ms	1.56x
wall clock	4.7 s	6.8 s	1.44x
queries sent	50,000	50,000
cpu	32.5 s	40.4 s	1.24x
cpu, % of wall	685%	591%
waiting for a core	3.8 ms	15,065.5 ms	3,983.78x
migrations	0	84,121
faults min/maj	0 / 0	1,261 / 0
peak RSS	29.4 GiB	43.6 GiB	1.49x
disk written	0	0
disk read	0	0

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

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	6,481	4,865	1.33x
recall@10	0.9399	0.9441	~equal
client p50	1.23 ms	1.54 ms	1.25x
client p99	1.92 ms	3.02 ms	1.57x
client p99.9	2.39 ms	3.73 ms	1.56x
server p50	1.13 ms	1.32 ms	1.17x
server p99	1.81 ms	2.66 ms	1.47x
wall clock	7.8 s	10.3 s	1.33x
queries sent	50,000	50,000
cpu	54.5 s	65.3 s	1.20x
cpu, % of wall	701%	633%
waiting for a core	5.4 ms	38,874.7 ms	7,258.48x
migrations	0	155,076
faults min/maj	0 / 0	1,194 / 0
peak RSS	29.4 GiB	43.6 GiB	1.49x
disk written	0	0
disk read	0	0

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

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	3,799	3,074	1.24x
recall@10	0.9667	0.9694	~equal
client p50	2.11 ms	2.52 ms	1.19x
client p99	3.27 ms	4.63 ms	1.41x
client p99.9	3.76 ms	5.69 ms	1.51x
server p50	2.00 ms	2.26 ms	1.13x
server p99	3.16 ms	4.22 ms	1.34x
wall clock	13.2 s	16.3 s	1.24x
queries sent	50,000	50,000
cpu	93.4 s	107.3 s	1.15x
cpu, % of wall	707%	659%
waiting for a core	8.8 ms	58,175.7 ms	6,645.12x
migrations	0	178,808
faults min/maj	0 / 0	647 / 0
peak RSS	29.4 GiB	43.6 GiB	1.49x
disk written	0	0
disk read	0	0

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

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,181	1,854	1.18x
recall@10	0.9812	0.9822	~equal
client p50	3.66 ms	4.23 ms	1.16x
client p99	5.78 ms	7.42 ms	1.28x
client p99.9	6.60 ms	8.94 ms	1.35x
server p50	3.54 ms	3.94 ms	1.11x
server p99	5.67 ms	6.98 ms	1.23x
wall clock	23.0 s	27.0 s	1.18x
queries sent	50,000	50,000
cpu	162.2 s	186.5 s	1.15x
cpu, % of wall	706%	690%
waiting for a core	15.2 ms	81,122.1 ms	5,330.22x
migrations	0	193,845
faults min/maj	0 / 0	664 / 0
peak RSS	29.4 GiB	43.6 GiB	1.49x
disk written	0	0
disk read	0	0

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

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,235	1,068	1.16x
recall@10	0.9892	0.9901	~equal
client p50	6.44 ms	7.39 ms	1.15x
client p99	10.35 ms	12.24 ms	1.18x
client p99.9	11.85 ms	14.06 ms	1.19x
server p50	6.32 ms	7.01 ms	1.11x
server p99	10.22 ms	11.74 ms	1.15x
wall clock	40.5 s	46.9 s	1.16x
queries sent	50,000	50,000
cpu	285.5 s	335.4 s	1.17x
cpu, % of wall	704%	716%
waiting for a core	25.5 ms	110,818.9 ms	4,337.95x
migrations	0	195,531
faults min/maj	3 / 0	1,846 / 0
peak RSS	29.4 GiB	43.6 GiB	1.49x
disk written	0	0
disk read	0	0

W12-upload filtered search: load 200,000 with payloads

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

metric	strawmANN	Qdrant
wall clock	45.8 s	98.6 s	2.15x
of which upload	1.5 s	5.8 s	3.79x
of which index wait	39.1 s	90.2 s	2.31x
time to Green	39.1 s	90.2 s	2.31x
cpu	297.7 s	520.5 s	1.75x
cpu, % of wall	650%	528%
waiting for a core	166.6 ms	10,982.4 ms	65.91x
migrations	0	7,863
faults min/maj	445,699 / 34	372,899 / 446,815
peak RSS	31.6 GiB	43.6 GiB	1.38x
disk written	1.1 GiB	5.3 GiB
disk read	588.0 KiB	61.1 MiB

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

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,869	1,616	1.16x
recall@10	1.0000	0.9995	~equal
client p50	1.06 ms	1.24 ms	1.16x
client p99	1.13 ms	1.44 ms	1.27x
client p99.9	1.19 ms	1.51 ms	1.28x
server p50	967 µs	1.12 ms	1.15x
server p99	1.02 ms	1.30 ms	1.27x
wall clock	26.8 s	31.0 s	1.16x
queries sent	50,000	50,000
cpu	49.5 s	62.7 s	1.27x
cpu, % of wall	185%	202%
waiting for a core	4.5 ms	21.6 ms	4.76x
migrations	0	17,479
faults min/maj	0 / 0	1,065 / 0
peak RSS	31.6 GiB	43.6 GiB	1.38x
disk written	0	0
disk read	0	0

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)

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	822	823	-
recall@10	0.9893	0.9720
client p50	2.49 ms	2.44 ms
client p99	3.03 ms	2.78 ms
client p99.9	3.21 ms	2.94 ms
server p50	2.38 ms	2.29 ms
server p99	2.93 ms	2.62 ms
wall clock	60.9 s	60.8 s
queries sent	50,000	50,000
cpu	118.1 s	122.3 s
cpu, % of wall	194%	201%
waiting for a core	6.9 ms	131.2 ms
migrations	0	19,113
faults min/maj	0 / 0	997 / 0
peak RSS	31.6 GiB	43.6 GiB
disk written	0	0
disk read	0	0

recall unequal: 0.9893 vs 0.9720; §7.4 compares at equal recall 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)

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	1,864	3,397	-
recall@10	1.0000	0.9804
client p50	1.07 ms	585 µs
client p99	1.13 ms	687 µs
client p99.9	1.18 ms	752 µs
server p50	969 µs	473 µs
server p99	1.02 ms	561 µs
wall clock	26.9 s	14.8 s
queries sent	50,000	50,000
cpu	49.5 s	29.8 s
cpu, % of wall	184%	202%
waiting for a core	1.1 ms	11.6 ms
migrations	0	10,549
faults min/maj	0 / 0	304 / 0
peak RSS	31.6 GiB	43.6 GiB
disk written	0	0
disk read	0	0

recall unequal: 1.0000 vs 0.9804; §7.4 compares at equal recall

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

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,862	2,412	0.77x
recall@10	1.0000	0.9965	~equal
client p50	1.07 ms	826 µs	0.77x
client p99	1.13 ms	956 µs	0.85x
client p99.9	1.19 ms	1.02 ms	0.86x
server p50	969 µs	712 µs	0.73x
server p99	1.02 ms	829 µs	0.81x
wall clock	26.9 s	20.8 s	0.77x
queries sent	50,000	50,000
cpu	49.4 s	42.0 s	0.85x
cpu, % of wall	184%	202%
waiting for a core	1.7 ms	10.9 ms	6.25x
migrations	0	13,463
faults min/maj	0 / 0	309 / 0
peak RSS	31.6 GiB	43.6 GiB	1.38x
disk written	0	0
disk read	0	0

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

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,864	1,636	1.14x
recall@10	1.0000	0.9995	~equal
client p50	1.07 ms	1.22 ms	1.14x
client p99	1.13 ms	1.41 ms	1.25x
client p99.9	1.17 ms	1.49 ms	1.28x
server p50	969 µs	1.10 ms	1.14x
server p99	1.02 ms	1.28 ms	1.26x
wall clock	26.9 s	30.6 s	1.14x
queries sent	50,000	50,000
cpu	49.5 s	61.8 s	1.25x
cpu, % of wall	184%	202%
waiting for a core	1.4 ms	19.6 ms	13.77x
migrations	0	17,422
faults min/maj	0 / 0	581 / 0
peak RSS	31.6 GiB	43.6 GiB	1.38x
disk written	0	0
disk read	0	0

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

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	1,864	1,083	1.72x
recall@10	1.0000	0.9999	~equal
client p50	1.07 ms	1.85 ms	1.73x
client p99	1.13 ms	2.09 ms	1.85x
client p99.9	1.17 ms	2.19 ms	1.88x
server p50	968 µs	1.71 ms	1.77x
server p99	1.02 ms	1.94 ms	1.90x
wall clock	26.9 s	46.2 s	1.72x
queries sent	50,000	50,000
cpu	49.5 s	93.2 s	1.88x
cpu, % of wall	184%	202%
waiting for a core	1.1 ms	118.2 ms	108.00x
migrations	0	18,434
faults min/maj	0 / 0	723 / 0
peak RSS	31.6 GiB	43.6 GiB	1.38x
disk written	0	0
disk read	0	0

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

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	1,861	758	2.45x
recall@10	1.0000	1.0000	~equal
client p50	1.07 ms	2.63 ms	2.46x
client p99	1.13 ms	2.88 ms	2.54x
client p99.9	1.17 ms	3.17 ms	2.70x
server p50	971 µs	2.46 ms	2.54x
server p99	1.02 ms	2.68 ms	2.63x
wall clock	26.9 s	66.0 s	2.45x
queries sent	50,000	50,000
cpu	49.4 s	131.4 s	2.66x
cpu, % of wall	184%	199%
waiting for a core	1.9 ms	226.9 ms	118.69x
migrations	0	16,525
faults min/maj	0 / 0	1,210 / 0
peak RSS	31.6 GiB	43.6 GiB	1.38x
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	1,974	2,259	-
recall@10	0.9383	0.7668
client p50	1.02 ms	872 µs
client p99	1.32 ms	1.14 ms
client p99.9	1.56 ms	1.30 ms
server p50	923 µs	753 µs
server p99	1.22 ms	1.02 ms
wall clock	25.4 s	22.2 s
queries sent	50,000	50,000
cpu	47.0 s	44.9 s
cpu, % of wall	185%	202%
waiting for a core	7.4 ms	10.7 ms
migrations	0	15,993
faults min/maj	0 / 0	652 / 0
peak RSS	31.6 GiB	43.6 GiB
disk written	0	0
disk read	0	0

recall unequal: 0.9383 vs 0.7668; §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,312	1,400	-
recall@10	0.9728	0.9005
client p50	1.55 ms	1.42 ms
client p99	1.90 ms	1.73 ms
client p99.9	2.16 ms	1.89 ms
server p50	1.45 ms	1.29 ms
server p99	1.80 ms	1.58 ms
wall clock	38.1 s	35.8 s
queries sent	50,000	50,000
cpu	72.6 s	72.3 s
cpu, % of wall	190%	202%
waiting for a core	10.3 ms	38.0 ms
migrations	0	19,122
faults min/maj	0 / 0	736 / 0
peak RSS	31.6 GiB	43.6 GiB
disk written	0	0
disk read	0	0

recall unequal: 0.9728 vs 0.9005; §7.4 compares at equal recall

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

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	822	822	-
recall@10	0.9893	0.9720
client p50	2.49 ms	2.44 ms
client p99	3.03 ms	2.79 ms
client p99.9	3.22 ms	2.93 ms
server p50	2.38 ms	2.29 ms
server p99	2.93 ms	2.63 ms
wall clock	60.9 s	60.9 s
queries sent	50,000	50,000
cpu	118.0 s	122.5 s
cpu, % of wall	194%	201%
waiting for a core	10.3 ms	154.7 ms
migrations	0	19,663
faults min/maj	0 / 0	1,051 / 0
peak RSS	31.6 GiB	43.6 GiB
disk written	0	0
disk read	0	0

recall unequal: 0.9893 vs 0.9720; §7.4 compares at equal recall

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

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	480	486	parity
recall@10	0.9959	0.9945	~equal
client p50	4.23 ms	4.13 ms	0.98x
client p99	5.27 ms	4.75 ms	0.90x
client p99.9	5.55 ms	5.11 ms	0.92x
server p50	4.03 ms	3.94 ms	0.98x
server p99	5.03 ms	4.52 ms	0.90x
wall clock	104.3 s	103.0 s	~equal
queries sent	50,000	50,000
cpu	201.5 s	205.8 s	1.02x
cpu, % of wall	193%	200%
waiting for a core	17.9 ms	163.6 ms	9.15x
migrations	0	22,176
faults min/maj	0 / 0	2,134 / 0
peak RSS	31.6 GiB	43.6 GiB	1.38x
disk written	0	0
disk read	0	0

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

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

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	294	286	parity
recall@10	1.0000	0.9991	~equal
client p50	6.81 ms	6.99 ms	1.03x
client p99	7.56 ms	8.12 ms	1.07x
client p99.9	7.85 ms	8.46 ms	1.08x
server p50	6.42 ms	6.71 ms	1.05x
server p99	6.98 ms	7.82 ms	1.12x
wall clock	170.2 s	174.8 s	1.03x
queries sent	50,000	50,000
cpu	325.0 s	348.9 s	1.07x
cpu, % of wall	191%	200%
waiting for a core	38.1 ms	140.4 ms	3.69x
migrations	0	23,563
faults min/maj	0 / 0	4,057 / 0
peak RSS	31.6 GiB	43.6 GiB	1.38x
disk written	0	0
disk read	0	0

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

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	51,141	46,852	1.09x
client p50	137 µs	157 µs	1.15x
client p99	230 µs	293 µs	1.27x
client p99.9	267 µs	446 µs	1.67x
server p50	11 µs	28 µs	2.55x
server p99	16 µs	90 µs	5.60x
wall clock	4.0 s	2.2 s	0.55x
queries sent	200,000	100,000
cpu	5.6 s	9.1 s	1.63x
cpu, % of wall	138%	413%
waiting for a core	4.2 ms	853.7 ms	201.15x
migrations	0	108,063
faults min/maj	0 / 0	780 / 0
peak RSS	31.6 GiB	43.6 GiB	1.38x
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 (12x), 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.25x less work per query x 0.33x cores busy during the row (1.40 against 4.23) 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 49,500 synthetic points append

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

metric	strawmANN	Qdrant
queries/second	580	504	-
client p50	9.02 ms	31.01 ms
client p99	34.05 ms	68.87 ms
client p99.9	114.14 ms	82.97 ms
server p50	8.39 ms	30.23 ms
server p99	33.20 ms	67.88 ms
wall clock	45.0 s	114.4 s
queries sent	31,122	31,122
cpu	351.5 s	900.4 s
cpu, % of wall	781%	787%
waiting for a core	263,490.0 ms	784,454.5 ms
migrations	1,118	58,423
faults min/maj	580,619 / 91,221	889,903 / 147,520
peak RSS	35.1 GiB	43.6 GiB
disk written	290.0 MiB	12.5 GiB
disk read	71.8 MiB	161.2 MiB

strawmANN: qps over the 26.1 s the append ran (726 over the whole search); append 1,900 points/s Qdrant: qps over the 26.0 s the append ran (272 over the whole search); append 1,900 points/s search-during-write; no recall join

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

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

metric	strawmANN	Qdrant
queries/second	251	99	-
client p50	21.89 ms	70.85 ms
client p99	113.84 ms	186.56 ms
client p99.9	140.08 ms	1,871.42 ms
server p50	20.74 ms	69.57 ms
server p99	112.83 ms	184.99 ms
wall clock	31.7 s	80.2 s
queries sent	7,945	7,945
cpu	476.4 s	652.0 s
cpu, % of wall	1,503%	813%
waiting for a core	208,739.9 ms	518,000.9 ms
migrations	806	25,478
faults min/maj	1,020,754 / 298,410	769,832 / 324,970
peak RSS	35.1 GiB	43.6 GiB
disk written	1.1 GiB	8.9 GiB
disk read	13.4 MiB	77.2 MiB

strawmANN: qps over the 31.7 s the append ran (251 over the whole search); write overlap 53%; search covered 53% of the append; append 3,300 points/s Qdrant: qps over the 82.1 s the append ran (97 over the whole search); search covered 97% of the append; append 2,396 points/s search-during-write; no recall join; the search saw under 90% of strawmANN's append, so its qps is the append's start and not all of it

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.

strawmANN gate pass

environment hash 373e8531fd3d1bf6

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(5%)

measurement profile: as-deployed

Qdrant gate pass

environment hash 373e8531fd3d1bf6

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

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-dbp1m-perf-0930 qd-dbp1m-perf-0930.

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

W10: throughput against ef

Per workload

Time spent waiting for a core

Peak memory per row

Time stalled on I/O

Time stalled on memory

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.32x

W1 ingest throughput

W2 index build time

W3 search, fp32, single query 1.70x

W4 search, saturating (closed loop) 1.02x

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.71x

W6-upload scalar quantization: load

W6 quantized: scalar 1.50x

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

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

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

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

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

W7-upload binary quantization: load

W7 quantized: binary + oversampling 1.16x

W8-upload PQ: load

W8 quantized: PQ 1.34x

W9 exact / brute force 1.33x

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

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

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

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

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

W12-upload filtered search: load 200,000 with payloads

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

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

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

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

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

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

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

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)

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

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

W13 scroll / pagination 1.09x

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

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

Ambient load per row

strawmANN gate pass

Qdrant gate pass

Recall by `ef`