# Recorded measurements

A review of draft 2 observed that every performance figure in §7 was an
assertion with no benchmark, command, machine or sample behind it, and
that the FTS size could not be reconciled with the stated schema. Both
were fair. This file is the answer: `tools/bench` produces it, and §7
cites it rather than restating numbers.

## Machine and command

```
linux/amd64, 16 cpu, go1.26.5
go build -o bench ./tools/bench
./bench --corpus /home/paulca/amadan.net/oficina --chunks 90000
```

Run 2026-09-03. The corpus is every `.md` in the oficina tree, chunked by
**memoria's own chunker** (`internal/memoria/chunk`), then cycled to reach
the target count. Cycling repeats vocabulary, so the FTS figures are
**optimistic**: genuinely varied English produces a larger postings list.

## What a memoria chunk actually is

650 chunks from the real corpus, **mean 202 words / 1325 bytes**.

This corrects draft 2, which assumed 400 words and ~1.6 KB. The chunker
targets 400 words but folds runts and never straddles a heading, and real
documents have headings every few paragraphs — so the mean lands at about
half the target. Every figure below follows from the measured size, not
the intended one.

At 90,000 chunks that is **113.8 MB of text**.

## FTS5

| schema | index size | bytes/chunk | build | one BM25 query |
|---|---|---|---|---|
| `fts5(body, tokenize='porter unicode61')` | **200.0 MB** | 2329 | 6.8 s | 1.09 ms |
| `fts5(body, content='', tokenize=…)` | **49.3 MB** | 574 | 6.2 s | 1.09 ms |

**Draft 2 claimed 104 MB. That was wrong by about half.** A default FTS5
table keeps its own copy of the inserted text, which the earlier
measurement did not account for; the review caught this before the
arithmetic downstream of it was trusted.

The contentless table is **4× smaller** and just as fast to query, but it
cannot return column values, so `snippet()` does not work on it and
memoria would have to build its own highlight from the sealed chunk. That
is a real trade and §7 records it as a decision rather than an accident.

## Brute-force cosine, one goroutine, pure Go, no SIMD

Best of three runs. Draft 2 asserted 3.2 GFLOP/s; measured, it is 3.2
GFLOP/s, and every latency in draft 2's table was right to within a
millisecond.

| chunks × dims | measured | GFLOP/s | vectors f32 | vectors int8 |
|---|---|---|---|---|
| 10,000 × 512 | 3.18 ms | 3.2 | 20 MB | 5 MB |
| 90,000 × 512 | 28.9 ms | 3.2 | 176 MB | 44 MB |
| 100,000 × 768 | 49.2 ms | 3.1 | 293 MB | 73 MB |
| 250,000 × 512 | 80.0 ms | 3.2 | 488 MB | 122 MB |

## The wake footprint, recomputed

At 90,000 chunks:

| design | FTS | vectors | separate text | total |
|---|---|---|---|---|
| default FTS (text lives in the index) | 200 MB | 44 MB | — | **244 MB** |
| contentless FTS + text for snippets | 49 MB | 44 MB | 114 MB | **207 MB** |

So the ceiling under a 250 MB / 5-second budget is **about 90,000–110,000
chunks**, not the 150,000 draft 2 derived. Draft 1's ~100,000 was closer,
and draft 2's revision moved the number the wrong way while claiming to
have fixed the arithmetic.

## Still not measured

- Bucket read bandwidth and AES-GCM throughput on the platform. The
  50–100 MB/s and ~1 GB/s in §7.3 remain assumptions, and they are the
  inputs the ceiling is most sensitive to.
- The rest of a cold start: opening SQLite, allocating the vector matrix,
  parsing the snapshot, building id maps. The 5-second budget is spent on
  transfer and decryption alone, which flatters it.
- A corpus of genuinely varied English rather than a cycled one.