ZJX 1.29 REDLINE: A Third Objective, Measured Twice

Compact and fast are the objectives ZJX had before. Compact tries several representations of each input and keeps whichever produces the smallest complete archive; fast runs a fixed reduced schedule when creation time matters more than the last bytes. Both are unchanged in 1.29: on the qualification corpora their archives are byte-identical to what 1.28.0 writes. Ultrafast is the new one. It exists for the job where the archive has to be written and verified now, the storage bill is not the constraint, and a larger archive is an acceptable price.

What ultrafast does

Ultrafast makes one Zstandard level-1 attempt per unit of input and falls back to pass-through when compression does not pay. It runs no candidate search, no solid encoding, and no dictionary training. Creation runs through a deterministic parallel packer and testing through a streaming parallel verifier; both use four workers by default and accept one to eight. The worker count never changes the archive: one, two, four, and eight workers produce identical bytes on every qualified corpus, and every receipt records the workers requested and the workers used.

What ultrafast does not give up is the integrity contract. Every unit carries its own digest, the manifest and the archive carry theirs, metadata is exact under the same profile as the other objectives, and the archive is staged and published with one atomic rename. A 1.28.0 reader tests, inspects, and restores every qualified ultrafast archive. The 1.29 support contract states the rest: ultrafast requires the exact metadata profile, a request above eight workers is refused with the real limit rather than clamped, and the four-worker default admits about 65 MiB for creation and about 48 MiB for testing before any work starts.

Measured twice, reported twice

The qualified speed figures come from two campaigns on a quiesced laboratory host, and they are reported separately because they measured different cohorts. The metric is verified creation: create the archive, then verify it independently, in paired rounds against default tar | zstd -1, with 95% bootstrap intervals over the rounds. A ratio is the comparator's time over ZJX's time, so a value above one means ZJX finished first.

On the sealed development cohort of silesia, enwik8, and a synthetic deduplication case, the 1.29.0 default invocation measured 1.247x the verified-creation speed of default tar | zstd -1 (95% interval 1.223 to 1.267; Bonferroni-adjusted lower bound 1.221 over the three preregistered primary comparisons) at 1.0005x the archive bytes. That cohort is the one the recipe was calibrated on, which is why it could not be the only evidence.

On a held-out cohort that no ZJX or comparator measurement had touched before the freeze, the same default measured 1.1959x default tar | zstd -1 (95% interval 1.1867 to 1.2043). The two numbers are not averaged, pooled, or reconciled. Each stands for its own cohort. Both campaigns in full.

The holdout, in the open

The held-out cohort was built to remove the author's hand from the selection. An eligibility rule was written and digested before anything was enumerated: six workload classes, real data that already existed for ordinary operational reasons, between 64 MiB and 1 GiB per case, disjoint from every sealed corpus. Within each class the candidates were ordered by a hash seeded with the package digest and the first was taken. No compressor ran on any candidate during enumeration, selection, or snapshot. The result was six cases totalling about 1.86 GB: a production telemetry capture from a later day than the sealed one, an event-stream tick log, an application log, an agent session trace, a database snapshot, and a repository working tree of 24,997 files. They were frozen with a manifest, shipped to the laboratory host, digest-verified there, and measured exactly once against the unchanged package, alongside the four sealed members: 360 of 360 cells usable, every held-out case restored exactly before the timed rounds.

The preregistered gate on that cohort was not the default comparator. It was the matched thread budget, tar | zstd -1 -T4, as a class-weighted geometric mean over ten declared classes, with a required 95% lower bound of 0.80. The point estimate was 0.8236 and the 95% bootstrap lower bound was 0.8170. The gate passed. The margin was 0.017, and it deserves to be read with three facts beside it. ZJX was slower than the four-thread comparator on 7 of 10 individual cases and faster only on the three large-record cases. The six held-out cases alone aggregate to 0.7917 (95% interval 0.7832 to 0.8004), which would not have met the lower bound. And the pass rests on the declared class structure, in which the two telemetry captures count as two classes; counted as one, the ten-case reading is 0.7913. The verdict is the preregistered one, because changing the class structure after seeing the numbers would be exactly the reinterpretation the rules forbid, in either direction. It is recorded here as engineering transparency, not as a marketing figure.

What REDLINE did not achieve

ZJX 1.29 is not the fastest archiver or compressor, and the release does not claim to be. tar | zstd -1 with four threads or all threads is about 1.22x faster than the ZJX default on the development cohort and faster on seven of ten held-out cases. The full competitor field a leadership claim would need, including LZ4 and snappy at their multithreaded settings, was never assembled, so no leadership claim is eligible under the specification's own rules. BENCHMARK_LEADERSHIP_QUALIFIED is NO.

Ultrafast archives are larger. On the four-member cohort they were 27% to 1,000% larger than the fast objective's, which is the tradeoff the objective exists to make; compact and fast remain the choice for long-term storage. The four-worker default costs about 1.19x the CPU of default tar | zstd -1 and about 71 MB of peak memory against about 12 MB at one worker. Eight workers measured slower than four, and slower than the default comparator. The final development-cohort figure, 1.247x, came in below the interval an earlier candidate had recorded, 1.273 to 1.310, and the record says so rather than quoting the older number.

Against released 1.28.0 fast, ultrafast measured a creation ratio of 335x and a verified-creation ratio of 253x on the four-member cohort at the diagnostic tier. That figure is a comparison of two ZJX objectives with different goals, not a competitor result, and it appears nowhere on the homepage.

One more thing REDLINE did not do: rebuild the binary for publication. The package and executables report the version literal 1.29.0-rc3, because they are byte for byte the third release candidate that every gate measured. Rebuilding a passed candidate to change a string would have published bytes nobody had qualified.

The scar

Qualification found a defect. In the shipped safe build mode, the parallel verifier's helper threads were updating the resource governor's memory account from off the coordinator thread. The window was small: about one verification in a hundred of a small archive at four or eight workers ended in a panic instead of a result. It surfaced in the full test suite during the qualification of the second release candidate, after a package had already been built and measured.

That package and its campaigns were voided rather than repaired in place. The fix moves every governed allocation for the verifier onto the coordinator, which now allocates each helper's buffers before it spawns them and frees them after they join; a regression test runs six hundred rounds at eight workers and asserts the governor's account ends exactly where the owner left it. A new candidate was frozen, packaged once on the laboratory host, and requalified in full: every product gate, both campaigns, and a second independent read-only review. The fix has a measurable cost, about ten milliseconds per multi-worker test, because the coordinator now touches those buffers serially before any helper starts; it is the reason the third candidate verifies about 4% slower than the second at four workers, and it was accepted as the price of the invariant. It is the only code change between the second and third candidates.

What stays the same

Everything 1.28.0 promised, 1.29.0 promises unchanged: the workflow, the fidelity contract, the compatibility table, the package layout with its rootless installer, checksums, build provenance, and offline restore guide, and every documented limitation. The package alone, in an empty path, created, tested, and restored every qualified corpus. The one build change is that 1.29.0 targets a portable baseline x86-64 processor and selects the hardware digest implementation at run time, where the 1.28.0 package was tuned to its build host. Linux x86-64 with glibc remains the only supported platform. Availability, checksums, and package access.

The engineering lineage continues from 1.28 LOCKWIRE, which completed the workflow this release leaves intact. Choose compact when size matters, fast when balance matters, ultrafast when wall time matters. A scoped, paid evaluation measures all three against your own retention lane and your current method. Explore ZJX and discuss an evaluation. This Chronicle is free to read; commercial evaluation and business use follow separately agreed written terms.