Performance

Decode-speed benchmarks (sracha vs fasterq-dump/fastq-dump) live in the project README and reproduce with validation/benchmark.sh. This page covers the memory side of that story.

Peak memory (RSS)

Peak resident set size for a local decode (SRA file on disk → uncompressed FASTQ), measured with /usr/bin/time -v as the largest of three runs.

sracha is leaner than fasterq-dump on small files but uses more on large ones, and its peak RSS grows with archive size while fasterq-dump stays flat. That difference is a deliberate design choice, and the reported number overstates the real cost.

Why the numbers differ

sracha memory-maps each column's data for zero-copy decode — blob reads become plain slice operations with no syscall and no copy, which is a large part of the decode speedup. The cost is that pages touched during the stream count toward the process's resident set.

fasterq-dump takes the opposite approach: it reads each blob with a bounded positional read into a small reused buffer (KColumnDataRead → KFileRead in ncbi-vdb), and never maps the multi-GiB QUALITY/READ columns. The file bytes still land in the OS page cache, but as shared, reclaimable cache rather than private RSS — so its reported peak stays flat regardless of file size.

In short: sracha trades a higher reported peak RSS — most of it benign, reclaimable cache — for zero-copy decode speed. On memory-constrained hosts the mapped pages are reclaimed before any real pressure is felt.