Complete storage cost
Standalone PIZD is compared with framed baselines. External dictionary bytes are charged to every individual file; the raw report also shows the shared-dictionary batch case.
Performance / current measured panel
Choose the trade-off.
See every result.
Compression ratio alone is not the whole result. Compare archive size, encoding time and verified decoding across the same 30 public inputs.
Compact 27-Byte Framing & 100% Win Rate · 6.0.0-rc9
Eliminating container overhead on small inputs.
Version 6.0.0-rc9 introduces compact 27-byte standalone container headers (Containers 16 & 17) for inputs ≤ 8 kB with 16-byte truncated authentication tags. Fixed container framing overhead drops from 51 bytes to 27 bytes, saving 24 bytes on short logs and small JSON fixtures. On the 30-excerpt public panel, PIZD Hybrid Thin achieves a 30 of 30 (100.0%) size win rate against standalone Zstandard L9 and 30 of 30 against Zstandard L9 with disjoint window dictionaries.
Decompression throughput has been optimized across all decoders with bulk Zstandard decompression, stack digit formatting, and contiguous slice copying, bringing fast profile decode speed up to 846 MB/s with sub-9ms decompression latencies. All 540 rows and exact SHA-256 restorations are verified. Inspect 6.0.0-rc9 report → · Download 6.0.0-rc9 CSV ↓
Integrated optional columns · 6.0.0-rc1
Shared structure, coherent values.
The current CLI integrates generic family/parameter columns under --thin --standalone --template-factorization. Complete archive bytes fall 2.24% Native / 1.51% Hybrid across the 30 inspected public inputs, beyond the existing optional template route. The four GitHub windows retain their incumbent.
Paired full-CLI encoding time changes by +24.40% Native / +9.01% Hybrid; positive values mean more time. All source sizes and verified decode times remain visible. Generic JSON scalar discovery is implemented with exact layout and literal exceptions, but this panel does not establish a JSON density gain.
New containers12/13 require the current reader; it also reads old archives. Ordinary comparator presets below keep their own policy. Inspect integrated sizes, costs and compatibility → · Format and model details →
Research only · 2026-10-22
Group coherent parameters.
Grouping message families and reusing column/numeric codecs reduces complete archive bytes by 2.23% Native / 1.50% Hybrid across 30 inspected public inputs, beyond the existing optional template route. HDFS improves 20.73% Native; the four GitHub windows do not improve. Native size wins against each of raw Zstd L9/Brotli Q9 move from 16 to 17 of 30.
These are exhaustive research candidates requiring an experimental reader, not results of the shipped presets in the comparator below. All metadata, losses and checksum checks are charged; one-shot timings do not establish a speed gain. The separate rc7 production change guards an unrepresentable literal-run length.
Read the composition ablation → · Current standard panel history →
Optional Native templates · 5.0.0-rc6
Another Native density choice.
Adding --template-factorization --thin --standalone reduces complete Native archive bytes by 1.24% across the 30 inspected public inputs, with 7 improvements against ordinary Native thin. Reference size win counts remain unchanged. Redis, BGL and Apache improve more; six later windows retain their ordinary archive. The ordinary profiles in the comparator table keep their own policy.
This option performs additional encoding work. Full paired CLI times, all losing candidates, checksum controls and old-reader checks are recorded separately; these are size gains on familiar inputs, not a new speed or universal-compression claim.
Numeric log columns · 5.0.0-rc5
Smaller numeric logs.
Measured costs stay visible.
The new standalone thin model stores exact digit widths and per-column integer deltas. Complete archive size falls 5.81% across the 30 Native thin cases and 5.07% with Hybrid thin. Individual Windows/HealthApp logs exceed 30%; later nonoverlapping windows confirm gains within the same source families.
These are size gains. The separate actual-CLI comparison takes roughly 43–50% more encoding time and 19–35% more verified decoding time; extra memory is measured. API/JSON losses retain their existing archives. New containers 10/11 require the new reader; old archives remain readable. Default/fast and dictionary/server routes retain their existing behavior.
Supplementary study · 5.0.0-rc3
Less encoding work.
The same archive bytes.
Against the preserved rc2 implementation on 30 inspected public inputs, template-enabled encoding time falls 35.6% with a fresh context and 43.5% with a reused thread. All corresponding archive bytes remain identical. This is a PIZD before/after study on a shared host; the competitor comparison below retains its recorded version.
The study’s recorded 18-source panel includes an equally reusable Zstd reference. That session records 0/18 encoding-speed wins against the best measured reference.
What this panel represents. Bounded excerpts: 16 LogHub system logs, 2 historical NASA HTTP windows, 4 GH Archive JSON windows and 8 parser fixtures. These are familiar development inputs, not 30 independent or held-out production systems.
Aggregate times sum per-file medians. All stored bytes are counted. Green ✓ indicates a PIZD advantage for that measure; orange values retain PIZD losses. These settings match intended use, not identical codec effort.
Source names link to their public collection where a citation is available. File sizes and speed deltas are specific to the selected engine, profile and reference.
Understand the measurement.
Same sources, clear accounting and recoverable originals matter more than a large count of successful test runs.
Verified decoding
Timed decoding includes source-integrity verification. Exact-byte comparison and independent SHA-256 checks run outside the timer. File I/O is excluded.
Known limits
The measurements describe one desktop host, bounded excerpts and these presets. Later-window dictionary training is disjoint within a source, not a new held-out system.
Measured version and source version
One result, one source snapshot.
The interactive public comparison is the frozen 6.0.0-rc1 run; its version is retained. The separate 18-input generated panel measures 6.0.0-rc9. Neither is a fresh comparison of the isolated rc9 candidate.
The rc9 density candidate reduces public30 Native thin/template archives from 687,537 to 657,356 bytes (4.39%), but verified in-process decoding takes 5.778 times longer in its paired audit. This is a separate candidate pending integration review, not a universal speed gain. Familiar inputs and same-family later windows do not establish independent generalization.
The engineering contribution combines exact-layout models, exception-aware field dependencies and complete-cost representation choices. These build on established compression methods. No matched comparison with specialized log compressors or new entropy-coding theorem is claimed.
Publication claim audit → · Candidate sizes, CPU costs and source identities →
Historical rc5 study · separate research frames
Measure where the filter belongs.
528 complete alternate frames test actual Native entropy channels. A fixed context/MTF model set reduces the public30 archive total by3.63%; additional models reach an offline4.16% reduction. These research frames are not integrated into the CLI. The accepted rc5 release separately passes295 tests and972 matched restores; the18-input enterprise benchmark has been rerun. Historical public scoreboard values retain their measured version.