[DanielLuning]

What changed

• examples/codecs.exs: the Measured block, the expected-verdict line, the base58 baseline ratios, the recommendation and the three report reasons now match three runs on 2026-10-20. A new paragraph says why the kernels got faster.
• docs/performance.md: 6.2 records the bisect (encode64 489 -> 251-260 us at the defk-upc merge 1ba1838); 1.7, 3.4, 5.x (single key) and 7 (fast64) quote the new numbers.
• examples/_tables.exs and examples/README.md: the codecs line says "one key per call is about as fast as Elixir"; the prose line has the new ratios. The tables were regenerated with mix defk.docs; examples/scoreboard.json is unchanged (its codecs row is the quiet 2026-10-19 measurement).

Results

Provisional: other processes used 0.6-2.3 cores beside the runs. Best of 15, three runs, M-series Mac.

	Elixir	defk	speedup	header before
base64 1 MB	3.05-3.11 ms	0.47-0.50 ms	6.1-6.7x	2.94-3.04x
hex 1 MB	2.38-2.43 ms	0.67 ms	3.56-3.63x	2.02-2.04x
base58 10k keys	11.2-11.8 ms	3.28-3.35 ms	3.35-3.55x	2.59-2.68x

• fast64 is now 4.1-4.4x slower than the base64 kernel (was 2.1x).
• hex encode alone is 2.6-2.7x over :binary.encode_hex (was 1.5x), decode 4.3-4.7x.
• One base58 key per call: Elixir 0.86-1.43 us, defk 0.91-1.06 us: about level.
• Cause, for base64 and hex: range facts for constant multiples of a loop index (defk-upc, 2026-10-10) drop the bounds and overflow checks on s[3 * g], out[4 * g] and 2 * i. git bisect --first-parent over main from 7365e4a to 2595489, timing encode64 alone. The base58 gain was not bisected.

How it was checked

mix ci green in the worktree on the Mac (2305 passed). mix defk.examples --only codecs ok (3 checks).

• Touches a promised surface (kernel subset, runtime contract, public API, error codes)? Then a CHANGELOG.md entry, and a deprecation for a rename or removal (docs/guides/stability.md).
• Touches test/stability/? A frozen file is never edited; a release adds a directory (docs/agents/stability.md).