Every comparison, exact figures.

Featured campaign

Input

Real service telemetry, one JSONL capture from 2026-06-03: 342,409,609 bytes, 681,648 records, SHA-256 prefix 9775bf5d. The capture is private.

ZJX

1.29.0 REDLINE, the current release; compact and fast are unchanged from 1.28.0 (REDLINE gate P6: byte-identical archives)

Bytes written by

1.28.0 LOCKWIRE, the executable shipped in the released Linux package; source revision 30307f19, executable SHA-256 prefix 10ee0d9e

Objective

compact; the fast objective wrote 4,412,984 bytes on the same input

Measured

2026-09-06

Metric

Complete archive bytes, format overhead included. MB is decimal (1,000,000 bytes).

Comparators

14 configurations of ten tools at strong settings, the world baseline set the ZJX laboratory uses; 14/14 completed. Several tools appear with more than one setting.

Verification

zjx test passed; restored file matched the source SHA-256; every comparator archive was decompressed and matched too. Restored bytes were compared with the source.

Result

ZJX compact 4,412,984 bytes against 7,125,674 bytes for zpaq -m5: 38.1% smaller than the strongest comparator and 98.7% smaller than the raw input.

Telemetry is what ZJX is built for, and this is its flagship size comparison: one real capture, fourteen comparator configurations, every archive restored and matched. Your own data is measured in a commercial evaluation. REDLINE gate P6 confirmed byte-identical compact and fast archives against 1.28.0, so this result, written by the 1.28.0 LOCKWIRE executable on 2026-09-06, is the 1.29.0 result.

All configurations

The strongest comparator is the smallest completed and verified non-ZJX archive. Percentages are 100 × (1 − ZJX bytes ÷ comparator bytes); a negative result would read as larger, an equal result as same size.

Every row on one scale

A linear axis from zero to the largest archive, 57.00 MB. No row is rescaled, truncated, or omitted.

1. ZJX 1.29.0 compact4,412,984
2. ZJX 1.29.0 fast4,412,984
3. zpaq -m57,125,674
4. zstd --ultra -22 --long=31 (tar)7,280,110
5. brotli -q 11 (tar)7,345,538
6. xz -9e (tar)7,612,052
7. zstd -19 --long=31 (tar)7,800,328
8. zstd -19 (tar)8,149,050
9. 7-Zip LZMA2 -mx=9, single thread9,392,518
10. 7-Zip LZMA2 -mx=99,666,962
11. RAR5 -m59,842,920
12. 7-Zip PPMd -mx=912,612,270
13. bzip2 -9 (tar)34,456,468
14. gzip -9 (tar)40,176,031
15. zip -9 (deflate)40,176,334
16. lz4 -12 (tar)56,999,958

Derivation

Exact bytes are the stored facts; percentages and megabytes are derived at build time and in the browser from the same module, so every surface rounds the same way.

signed_reduction_percent = 100 × (1 − Z / C)   with comparator bytes C > 0
raw_reduction_percent    = 100 × (1 − Z / R)   with raw input bytes R > 0
MB = bytes / 1,000,000

Featured values: Z = 4,412,984, C = 7,125,674, R = 342,409,609. Result: 38.1% against the comparator, 98.7% against raw input. Nothing is calculated from rounded megabyte strings.

Timing is indicative only

Wall time and peak memory in the size campaign come from single sequential runs on the quiesced ZJX laboratory host. Read them as order of magnitude. ZJX speed is qualified separately, in the REDLINE campaigns below.

REDLINE verified-creation campaigns

Verified creation: archive creation plus an independent integrity check, 12 paired rounds per campaign, class-weighted geometric mean of per-round ratios, 95% bootstrap intervals. Subject: ZJX 1.29.0 ultrafast objective, four workers, then an independent test. Comparators: tar | zstd -1 (default, single admitted thread), verified by zstd -t, and tar | zstd -1 -T4 (four threads, the matched thread budget). Host: Quiesced laboratory host under an exclusive lease, 8 logical CPUs; the measured executable is the one shipped in the released package. A ratio is comparator time over ZJX time, so a value above 1 means ZJX was faster. The two campaigns measured different cohorts and each is reported on its own.

Development cohort (RG017): worker sweep and thread budgets

Sealed development cohort: silesia, enwik8, and a synthetic deduplication case; 12 paired rounds, 468 of 468 cells usable. The cohort the recipe was calibrated on. Archive bytes were identical at every worker count and byte-identical to both earlier release candidates. The qualified ultrafast configuration with four workers costs about 1.19x the CPU of default tar | zstd -1 and admits about 65 MiB at the default 4 MiB units and four workers (about 71 MB at four workers against about 12 MB at one).

Four workers is the sweet spot: it beats one, two, and eight workers, on this development cohort.

Held-out cohort (RG018): every case, both lanes

Four sealed members plus six privately held-out cases (about 1.86 GB, six workload classes) selected by a rule frozen before any measurement; ten classes, 12 paired rounds, 360 of 360 cells usable, run once. The six held-out cases were selected by a written eligibility rule and a deterministic hash before any compressor touched them, frozen with a manifest, and measured once against the unchanged package; 6 of 6 held-out cases restored exactly before the timed rounds. They are described here by workload class and size only. The gate lane compares ZJX ultrafast with four workers against tar | zstd -1 -T4 (four threads, the matched thread budget); the reported lane compares it with tar | zstd -1 (default, single admitted thread), verified by zstd -t. The last column is ZJX archive bytes over the comparator's.

The gate verdict follows the class structure fixed before measurement, where the two telemetry captures count as two classes (as one class, the ten-case reading is 0.7913). Against the four-thread comparator, ZJX led on the three large-record cases.

Public release record · REDLINE source note · Release Chronicle · The 1.29 support contract

How to read a measurement

Start with the version, dataset, settings, and comparison target. Then ask which operation was measured, whether every comparator completed, and exactly what was verified. Complete archive size includes format overhead; comparing it with raw input answers a different question from comparing it with another compressed archive, and the second question is the one that prices a migration.

• Creation time: elapsed time to make an archive. Less time is not the same percentage as increased speed. Qualified timings come from a dedicated controlled host.
• Memory: peak RSS is observed process memory. Configured limits and reserved memory are separate quantities.
• Restoration: archive integrity testing, exact source comparison, and metadata comparison must be named separately.
• Money: multiply the size advantage by eligible retained bytes and the storage rate you actually pay, then subtract compute, temporary space, migration, licensing, and restoration cost. The savings page does the first step only.

Missing measurements are Not reported, never zero.

Historical records

Earlier results from before the current campaign format, listed for lineage. Some compare with raw input rather than a competitor archive.

Previous campaign on the same input

ZJX 1.27 CIPHERGLASS (2026-09-05, development host) wrote 4,412,968 bytes for the compact objective against the same 7,125,674-byte strongest comparator. The 1.28.0 archive is exactly 16 bytes larger: the manifest-integrity footer LOCKWIRE adds to every archive. Previous campaign source note

Pre-NIGHTMARKET size records (incomplete version attribution)

Exact ZJX version and compression settings are not reported for these rows; they stay historical. Historical source note, updated 2026-08-22

Raw-input example: Silesia v1, ZJX 1.21 STREAMWALL

Twelve files from a public benchmark collection, compared with the uncompressed input rather than a competitor archive. The 2026-08-30 record reports integrity testing and exact extraction under a 1 GiB host ceiling, 768 MiB ZJX memory ceiling, and 64 GiB temporary-disk ceiling. The exact compression profile is not named in the public note.

The reduction is 100 × (1 − 52,997,299 / 211,938,580) = 74.994%, rounded to 75.0%. The historical ZJX 1.2 reference failed without producing an archive, so its memory figure compares a completed run with an incomplete one. Original source note, archive digest, and conditions

Release-to-release measurements

NIGHTMARKET (Fast versus Compact on four corpora) and RELICWIRE (1.26 versus 1.25.1 creation time on two corpora) are release-to-release results, not competitor comparisons. They are summarized with their scope on the releases page. The REDLINE predecessor gate (ultrafast against released 1.28.0 fast: a creation ratio of 335x and a verified-creation ratio of 253x on the four-member cohort at the diagnostic tier, with ultrafast archives were 27% to 1,000% larger than fast's on those corpora) compares two objectives with different goals within ZJX.

Sources

• Telemetry comparator campaign source note, 2026-09-06: commands for every comparator, tool versions and executable digests, hashes, per-run observations
• Previous telemetry comparator campaign source note (ZJX 1.27 CIPHERGLASS), 2026-09-05
• ZJX 1.29.0 REDLINE public release record and source note: the qualified verified-creation figures and the held-out campaign
• Benchmark ledger on greyforge.tech, every experiment and its disposition
• Research index: every public source note and release record

The evaluation report includes the command recipes for your data. Commercial evaluation