Umbrella for the third-party crate survey run in August 2026. Each sub-issue is one dependency
question in the form CONTRIBUTING.md:58 asks for: raised in an issue before any PR, with the
reasoning written down.
Every sub-issue is expected to end in a written outcome, either "adopted, here is the
justification" or "declined, here is why", so that the same crate does not get re-surveyed in six
months. There is currently no place to write that down, which is itself one of the sub-issues.
Already covered elsewhere, deliberately not duplicated here
Already in the tree, so not re-proposed
The survey turned up several crates that this project already uses, which is a good sign about the
existing dependency choices: memmap2, rustc-hash, libdeflater, tempfile, assert_cmd,
mimalloc (with an explicit rationale in Cargo.toml), flate2 on the zlib-rs backend, bstr,
caps-sa.
Sub-issues
| # |
Subject |
Blocked by |
| #207 |
noodles 0.113 → 0.115, noodles-bgzf 0.49 → 0.51, plus the multithreaded BGZF writer question |
— |
| #202 |
sufr / libsufr vs the caps-sa incumbent (sibling of #162) |
— |
| #203 |
The rust-seq crates: packed-seq, simd-minimizers, seq-hash |
#204 |
| #204 |
A benchmark harness (divan or criterion) — enabler for everything below |
— |
| #205 |
Portable SIMD crate vs the hand-rolled intrinsics in simd_scan.rs |
#204 |
| #206 |
--limitBAMsortRAM aborts instead of spilling: external sort |
— |
| #208 |
Interval-overlap crates |
#204 |
| #209 |
DEPENDENCIES.md recording accepted and declined crates |
— |
| #210 |
Audit: does DashMap/HashMap iteration order reach any output? |
— |
| #218 |
Read other compressed input formats (bz2 / zstd / xz): niffler |
— |
Standing constraints for all of them
- Faithfulness to STAR is the product. A crate that changes which alignments are found, or the
order in which anything observable is emitted, is out regardless of its benchmarks.
- Determinism across thread counts. Output must not depend on
--runThreadN, on hash seeds,
or on an unspecified iteration order.
- Five platforms including Windows. A non-Rust dependency is a supply-chain and maintenance
decision, per CONTRIBUTING.md.
- Measure before optimising. Several sub-issues are explicitly blocked on the benchmark
harness, because there is no benches/ directory today.
Umbrella for the third-party crate survey run in August 2026. Each sub-issue is one dependency
question in the form
CONTRIBUTING.md:58asks for: raised in an issue before any PR, with thereasoning written down.
Every sub-issue is expected to end in a written outcome, either "adopted, here is the
justification" or "declined, here is why", so that the same crate does not get re-surveyed in six
months. There is currently no place to write that down, which is itself one of the sub-issues.
Already covered elsewhere, deliberately not duplicated here
libsais(vendored C viacc) for suffix-array constructionparaseqas an input option{C,V,,}BQor parallel readers forfastq) #97 — parallel inputs / parallel FASTQ readershyalitefor CR4Already in the tree, so not re-proposed
The survey turned up several crates that this project already uses, which is a good sign about the
existing dependency choices:
memmap2,rustc-hash,libdeflater,tempfile,assert_cmd,mimalloc(with an explicit rationale inCargo.toml),flate2on thezlib-rsbackend,bstr,caps-sa.Sub-issues
noodles0.113 → 0.115,noodles-bgzf0.49 → 0.51, plus the multithreaded BGZF writer questionsufr/libsufrvs thecaps-saincumbent (sibling of #162)rust-seqcrates:packed-seq,simd-minimizers,seq-hashsimd_scan.rs--limitBAMsortRAMaborts instead of spilling: external sortDEPENDENCIES.mdrecording accepted and declined cratesnifflerStanding constraints for all of them
order in which anything observable is emitted, is out regardless of its benchmarks.
--runThreadN, on hash seeds,or on an unspecified iteration order.
decision, per
CONTRIBUTING.md.harness, because there is no
benches/directory today.