Skip to content

1.2.0 — the same archives, less time

Choose a tag to compare

@drsamonline drsamonline released this 04 Nov 15:02
· 65 commits to main since this release

The same archives, less time. Every commit since 1.1.0 has been measurement or speed, and no archive size changed. Format stays v8: 1.1.0 and 1.2.0 read each other's archives.

What got faster

change effect archive
Huffman candidate gated by a 64 KiB trial 18% of a text run no longer spent on a candidate that never wins there unchanged on six corpora
LZMA2 fallback gated with a 20% margin 6.6 s → 4.1 s on a 1.6 MB mixed tree unchanged on six corpora
base64 gate: decisive 64 KiB first pass 1.76 s → 1.08 s where the answer is obvious unchanged
block digests checked in the decode workers strictly less serial work unchanged

Each of those is a trial that measures, not a rule that predicts — this project has three failed predictors behind it and does not want a fourth.

What was measured and not built

  • Block size swept at last (64 KiB to 16 MiB, four corpora): 4 MiB stays, 4.3–9.3% smaller than 256 KiB on homogeneous content, within 0.6% of the best everywhere.
  • An adaptive block size rejected, with its mechanism measured: removing BWT widens the 0.6% gap to 6.7%, so it is not the selector's freedom alone, and the trial would cost a second encode of every block.
  • Phase 4 opened: a .tar.zst costs 22.7% more through the engine than the tar itself; seeing inside zstd/brotli/xz is worth −18.5/−14.7/−16.9%. Recipe recovery settled as a shortlist, not a search (a search costs 2.5–4× the whole compression). Not built: it needs a corpus of real streams from other tools first.

One thing worth knowing

The development box reports two cores and delivers one core of throughput — two threads take as long as two sequential runs. Every thread claim in FINDINGS.md was measured there, so --parallel and -T are untested, not disproven. §0 of FINDINGS.md says so before the numbers it applies to.

Checks

34/34 suites, 53 CLI assertions, scripts/regression-corpus.sh green — on this build, in CI, and on the artifact attached here: a 1.6 MB asset tree round-tripped byte-exact at 319,947 bytes in 6.5 s.

ziptastic-1.2.0-linux-x86_64 is Linux x86-64, needs only glibc 2.17, and SHA256SUMS covers it. Full record: docs/FINDINGS.md.