Repository navigation
chaining: compact_a copies the anchor array three times #26
Description
compact_a (lchain.c:94) moves the anchor array a → b → a → b, three full copies of n_v × 24 bytes (sizeof(mb_anchor_t)):
lchain.c:103-107— gathera[v[…]]into a freshly-malloc'db[], reversing each chainlchain.c:123—memcpy(&a[k], &b[w[i].y>>32], …), reordering chains by target positionlchain.c:127—memcpy(b, a, k * …)back intob, solely so the oversizedacan be freed
The comment on the third makes the intent explicit: "write _a_ to _b_ and deallocate _a_ because _a_ is oversized, sometimes a lot." Freeing an oversized buffer is a good reason to exist; doing it with a third full pass is not the only way to get there.
The sort key at lchain.c:112-117 only needs b[k].tpos and b[k].sid at each chain start, which are reachable from a[v[…]] directly. Computing the chain-start offsets first, then gathering once from a into b in sorted order, would collapse all three passes into one — at the cost of a second index pass over u[].
Inherited verbatim from minimap2 (lchain.c:108 upstream).
Expected impact
Small. mb_lchain_dp, which inlines compact_a, is 6.2% of busy samples on HG002 HiFi 10k reads and 0.5% on HG002 WGS 1M pairs in a sample profile (arm64, 8 threads, hg38); rs_sort_mb128x adds 1.1% / 2.1%. These are memcpys of a compact array, so they run at streaming bandwidth and are a fraction of that share. This is a readability-and-allocation win first, a speed win second.
Activity