Repository navigation
chaining: the v[] peak-score recurrence in mb_lchain_dp is dead #25
Description
v[] is allocated at lchain.c:179 and filled by the peak-score recurrence at lchain.c:217:
v[i] = max_j >= 0 && v[max_j] > max_f? v[max_j] : max_f; // v[] keeps the peak score up to iThose values are never consumed. v[max_j] on that same line is the only reader, so the recurrence feeds nothing but itself. Inside mb_chain_backtrack v is write-only (v[n_v++] = i, lchain.c:81), and compact_a reads the anchor indices written there (lchain.c:106), never the DP scores.
The array itself must stay — the backtrack uses it as n-element scratch — but the recurrence and the int32_t it computes per anchor are dead.
Verification
Deleted line 217 outright, rebuilt, and diffed SAM against stock 95a79d4 (r419). All runs exited 0 with the expected record counts, and all four outputs were byte-identical:
| dataset | records | result |
|---|---|---|
chrM PE (test/) |
2,016 lines | identical |
| HG002 HiFi, 2k reads vs hg38 | 5,590 lines | identical |
| HG002 ONT R10, 2k reads vs hg38 | 6,117 lines | identical |
| HG002 WGS, 200k pairs vs hg38 | 405,287 lines | identical |
Also inherited from minimap2 (lchain.c:202), where the same line appears in the RMQ variant at :354 — worth checking whether it is live there before assuming it is dead everywhere.
Expected impact
Negligible as a speedup — one compare and one store per anchor in the outer loop of a DP whose inner loop runs up to max_iter times per anchor. Not worth doing for performance. Worth doing so the next reader does not have to work out that the comment is describing a value nobody uses.
Activity