perf(score): slide the splice-motif window across the junction scan (output-neutral)

[BenjaminDEMAILLE]

Slide the four-base splice-motif window across the junction scan instead of re-reading it at every position. Output-neutral, about 2.8% off the wall clock.

Where the time actually goes

Sampled a 2M-read run at 16 threads with symbols, ranked by self time:

function	samples
detect_splice_motif	15 456
find_best_junction_position	13 932
cluster_seeds	7 936
extend_alignment	6 741
stitch_recurse	4 908
compare_seq_to_genome	3 870

The top two are together roughly 45% of the on-CPU samples. Worth noting for anyone planning work here: the seed search is not the bottleneck on this workload. search_direction_sparse is 629 samples.

What changed

find_best_junction_position slides the junction one base per iteration and calls detect_splice_motif at each position. That function reads four genome bases: the intron's first two and its last two.

Because the junction moves by exactly one base, consecutive positions share two of those four. Moving right, the old d2 and a2 are the new d1 and a1; moving left, the old d1 and a1 are the new d2 and a2. Carrying them in a MotifWindow and sliding turns four genome reads per position into two.

Two smaller things fell out of the same reading:

• Whether the motif branch runs at all depends only on del, which does not change across the scan, so it is decided once before the loop instead of at every iteration.
• An out-of-range position becomes a sentinel byte that no motif arm matches, which is exactly what get_base returning None already meant. That removes four Option unwraps from the inner comparison without changing which positions produce NonCanonical.

detect_splice_motif keeps its signature and behaviour; it is now a one-line call into the same window type, so genomeGenerate's junction insertion and alignment scoring still share one truth table.

Verification

Output-neutral. SAM byte-identical to the parent commit on 200 000 real reads (ERR12389696, yeast), whole file including header.

Timing. Interleaved A/B, order flipped on even rounds, 2M reads, --runThreadN 16, --outSAMtype None so the measurement is alignment work and not the writer. Machine at 87-95% CPU idle, and the script refuses to run below 88%.

round	before	after
1	23.24 s	22.23 s
2	22.54 s	22.34 s
3	22.64 s	22.57 s
4	23.24 s	21.88 s
median	22.94 s	22.29 s

Same direction in all four rounds, about 2.8%. I will not oversell it: the spread within the "before" column is 0.7 s, so a single pair would not have been worth reporting. Four out of four in the same direction is what makes it readable, and the mechanism is arithmetic rather than a scheduling effect.

Modest against 45% of the profile, because most of that self time is the branchy scoring logic around the fetches rather than the fetches alone. The remaining hotspots in the table above are the next targets, and they are separate changes.

Gate: 560 lib + 26 integration tests, cargo clippy --all-targets -- -D warnings, cargo fmt --check, all green. No new dependency.

Related

The same profiling run produced two findings that live elsewhere: #168 records that the align path does about 1 000 heap allocations per read, with the measurement and the conclusion that removing 7.6% of them changes nothing measurable, and #166 fixes --runThreadN 1 running on every core, which is what made the thread-scaling curve behind this work readable in the first place.