Adds a streaming mode to uniwig (--streaming) that computes coverage counts with O(smooth_size) memory instead of O(chromosome_size). Processes BED input line-by-line using a sliding VecDeque window, supports all three count types (start/end/core), outputs WIG or bedGraph, and handles gzip transparently. Works with stdin/stdout for piping.

A key addition is sparse output — the existing batch mode always writes every position from 1 to chrom_size, even where counts are zero. Streaming defaults to emitting only non-zero positions, which dramatically reduces output size (1.2 GB vs 5.8 GB on 10M records) and is the main reason it's faster despite using a single thread.

The --dense flag controls gap handling: 0 (default) = sparse, -1 = fully dense (match batch behavior), and any positive N fills gaps ≤N bases wide. Default of 100 is essentially free.

Also fixes a bug in the batch path where all 3 count types were always computed regardless of -u flag — this was inflating batch runtimes by ~2.5x.

Usage

# Stream a BED file, output start counts as WIG
gtars uniwig --streaming -f regions.bed --chromref hg38.chrom.sizes -u start

# Pipe from stdin, output to stdout as bedGraph
cat sorted.bed | gtars uniwig --streaming --stdout -y bedgraph --chromref hg38.chrom.sizes

# Dense output (fill all gaps between data clusters)
gtars uniwig --streaming -f regions.bed --chromref hg38.chrom.sizes --dense -1

# Fill only small gaps (≤100bp)
gtars uniwig --streaming -f regions.bed --chromref hg38.chrom.sizes --dense 100

Benchmarks

Synthetic BED data, 10M records, 24 chromosomes, full hg38 sizes. --smoothsize 25 --stepsize 1 -u start -y wig:

Sparse streaming is faster (28s vs 43s), uses 2000x less memory (4 MB vs 8 GB), and produces 5x smaller output (1.2 GB vs 5.8 GB) — all on a single thread vs batch's 6 cores. Dense-for-dense, per-core throughput is roughly equivalent.