Batch PRs #167 and #185

[Psy-Fer]

Batch merge of the two output-neutral performance PRs from @BenjaminDEMAILLE, plus a fix to the benchmark harness found while measuring them. His commits are preserved with original authorship; the batch is split by commit so it reads PR by PR.

Closes #167
Closes #185

What's in it

PR	Commits	What
#167	289cfbe, 0c0ec81, 961366f	The splice-motif check in the junction scan carries a sliding window and looks the motif up in a table, instead of re-reading four genome bases and matching on them at every position. Consecutive junction positions share two of the four bases, so the scan does two genome reads per position rather than four.
#185	ba152cb, 91a848a	cluster_seeds reuses its window-bin map across reads on the same thread instead of allocating and rehashing per read, and moves each window's alignments into its cluster instead of cloning them.

#185's two commits were taken as their own increment. The PR displays the CellRanger stack beneath it, but the change itself touches only src/align/stitch.rs and applies onto main without any of it.

Changes made while merging

test/bench_ab.sh could not run on Linux cpu_idle used top -l 2 -n 0, which is macOS syntax; on Linux we can do top exits non-zero, set -o pipefail , and the script prints its header and exits 0 with no error. Separately, each round runs from a private temp directory but GENOME_DIR/READS were used as given, so relative paths stopped resolving after the cd — same silent-abort symptom. Both fixed: cpu_idle branches on uname and reads two /proc/stat samples a second apart on Linux, and both paths are absolutised at startup.

#167's CHANGELOG entry cited a benchmark the branch cannot produce — "the scan itself goes from 8.5 ns to 5.2 ns per iteration, measured by examples/jrbench.rs". jrbench has no before/after mode; it measures the current build across a range of del values, so it can produce one of those numbers and not the pair. Replaced with the wall-clock A/B below and a pointer to test/bench_ab.sh, which anyone can run.

Some CHANGELOG organisation cleanup

Validation

Output-neutral Records compared with headers excluded, since the @PG CL: line necessarily differs by output prefix:

	records differing from main
SE 10k yeast	0
PE 10k yeast	0
STARsolo default, 10x mouse chr19	0 (Gene matrix byte-identical)
SE, --runThreadN 1 vs --runThreadN 4	0

That last row is the one #185 needs. It introduces a thread_local! map reused across reads, so results could in principle depend on which reads a thread happened to process first. Checked structurally as well: win_bin is only ever get, insert and entry().or_insert() — it is never iterated, so its capacity cannot reach the output. The thread-count comparison confirms that empirically.

Against STAR 2.7.11b, unchanged from the recorded baselines:

Speed. Interleaved A/B, 100k yeast reads, --runThreadN 4, --outSAMtype None so the measurement is alignment work rather than the writer:

round	before	after
1	7.18 s	6.43 s
2	7.50 s	6.28 s
3	7.34 s	6.18 s
4	7.16 s	6.65 s
5	7.22 s	6.29 s
median	7.22 s	6.29 s

−12.9% median, 5 of 5 rounds kept, every round in the same direction. The spread within each column (0.34 s / 0.47 s) is well inside the gap.

The two PRs claimed ~2.8% and ~7% separately on a different workload (2M reads, 16 threads); those compound to roughly this, so the scale is consistent rather than surprising.

Reproduce with the dataset from CONTRIBUTING:

# build the "before" binary from the merge-base, then:
BENCH_MODE="None" BENCH_ARGS="--readFilesCommand zcat" \
  test/bench_ab.sh ./rustar-before ./target/release/rustar-aligner \
  "$DATA/indices_rustar" "$DATA/reads/ERR12389696_sub_1_100k.fastq.gz" 4 5