#74 reports: the cost is the seek, not the parse

[turner]

Closes #74.

The measurement ran on the server on 2026-09-06 against the real walk derivative. This branch records it and resolves the four places that were written as waiting on it.

The result

Over chr1:25,301,271 — 770 segments, ids 79335081–857, 2 contiguous runs:

arm	time	per segment
point+parse (today)	90.031 s	116.9 ms
point	73.219 s	95.1 ms
range+parse (the proposal)	0.306 s	0.4 ms
range	0.185 s	0.2 ms

The lookup dominates. So #75 keeps the shape it was written in — a range fetch behind a byte-identical oracle — and increment E needs no ADR. The parse-dominated branch, which would have meant numpy/pandas/a C extension in a project that has none, is closed.

One correction to the script's own output

walk-lookup-split.py derives the parse cost as point+parse − point = 16.811 s, and prints it as 19% of today. That is an artifact of the subtraction. The identical parse, over the same 770 rows into the same tables, measured as range+parse − range is 0.121 s — 0.157 ms/segment against 21.8, a factor of 139 for identical work. Both are medians of three passes.

The two arms differ in exactly one respect, so the 16.8 s is more lookup cost, not parse work that batching leaves behind. The real split is ~99.9% lookup. The perf record states this rather than reprinting 19% unqualified; the verdict is unchanged, only stronger.

What is deliberately not claimed

293.8x is a warm-cache ratio on one fixture and is not published as a speedup. Increment E's number is GenerateWalksMC's stage time on a cold ~10 kb region against the published 30.1 s, measured when #75 ships.

Two gaps, neither blocking #75

• The sparse fixture was not run. chr1:25,331,646 is 280 segments across a span of 5,569 in 5 runs, where a range fetch decompresses ~5,569 rows to use 280. Correctness there is covered by Stop reading the walk table one segment at a time #75's byte-identical oracle across all five fixtures; speed is not. It is the same measurement that would set the gap-coalescing parameter increment E ships at zero, so it is better taken against Stop reading the walk table one segment at a time #75's implementation than against the harness. Recorded as a new "Still open" bullet.
• GenerateWalksMC silently drops duplicate walk entries, and nobody knows how often #76's dup count did not come back. GenerateWalksMC silently drops duplicate walk entries, and nobody knows how often #76 stays on needs-info. Per its own "Note for Stop reading the walk table one segment at a time #75", it blocks nothing here.

Files

• docs/perf/walk-lookup-split-2026-09-06.md — new; raw output verbatim plus how to read it
• docs/tube-map-pipeline.html — "what is still unmeasured" → the answer
• docs/increment-e-batched-walk-reads.{html,md} — §7 collapses from a fork to a result; dateline updated; orphaned .fork CSS dropped
• docs/seqtubemap-roadmap.md — status paragraph, frontier table, dependency graph, Split GenerateWalksMC's per-segment cost between the lookup and the parse #74 ✅, Stop reading the walk table one segment at a time #75 unblocked, "Still open" bullet struck and replaced with the sparse-region question

🤖 Generated with Claude Code

https://claude.ai/code/session_013Q66fG2JF4diSxfYMEsGCW