The 30 seconds is shown rather than asserted, and the split is measurable

[turner]

docs/tube-map-pipeline.html described GenerateWalksMC's cost abstractly, and called the thing it looks up a node id — which is the one collision docs/lexicon.html names as the most expensive in the vocabulary. Those ids come off S lines; they are segments. That spelling had leaked from the code's variable names into the prose, including a table caption whose every number counts segments.

What the document now shows

Both files, byte for byte. The extracted subgraph, from the committed chr8 fixture, with the segment id bracketed as the only thing the walk table is indexed on — nine segments, no paths, nothing naming a person, and 464 W lines still to be manufactured. Then the .walk.gz row column by column: a placeholder chrom, the segment id in the position column (a genomic index repurposed as a segment-id index), and a column 4 listing all 464 haplotypes at that one segment in ~14 KB of text.

The loop in seven steps, ending on the point that a strand is only written after the whole file is exhausted — which is why a crash midway leaves a structurally valid GFA with no paths in it.

A new section on in what space the ids are contiguous, because the obvious reading is wrong. Segments do not tile the genome: 181810310 and 181810311 are the A and C of one SNP, occupying the same reference coordinates, and the walks prove it — CHM13 takes >309>311>312 where GRCh38 takes >309>310>312. No strand traverses both. The contiguity is in the integers, which is exactly what a range fetch asks for. The fixture table carries id range and span now, so the reader can see that two of five subgraphs are literally consecutive and that 770 segments sit in a span of 777.

The measurement

perf/walk-lookup-split.py is what the document says increment E is waiting on. Four arms over the same ids — point and range, each with and without the parse — so subtraction separates the seek from the parsing of ~177,000 coordinate entries:

parse	point+parse − point
lookup	point − range
E's time	range+parse, measured rather than predicted

Three things done deliberately: the parse is lifted verbatim from _write_walks_mc, because an approximation would make the subtraction meaningless; the range arm pays for the rows it does not want (a run spanning 5,569 ids to cover 280 segments hands back everything in between), rather than hiding that cost; and a warmup pass runs first so the arms are compared against each other instead of against whoever hit the cold page cache.

It needs the real derivative and so runs on the server. Verified here against a stub pysam — run grouping and the id filter are correct (4 segments with a gap → 2 runs, exactly 4 rows returned from an 8-id span). The real arms are untested; without pysam the script exits saying it belongs in the API's environment.

What this does not claim

Step 3 does not assert that the seek is the cost. The document already states that the seek-versus-parse split is unmeasured and can only be timed on the server, and it stays unmeasured until this script runs. Step 3 says steps 3 and 4 together are the 30 seconds and points forward to that paragraph.

Docs and a perf script only — no runtime code, which matters while main is what the live server tracks.

Stale line references fixed along the way: main.py:743-744 → 933-934, 200-202 → 231-234.

🤖 Generated with Claude Code

https://claude.ai/code/session_01J2Fbzw5Nq18SKvfKhDfdxA