ZXC: Lossless compression built for ultra-fast decode

Lobsters Hottest Tools

Summary

ZXC 0.15.0 正式发布,这是一款面向“一次压缩、多次解压”场景的无损压缩库 libzxc,采用 C 编写,解压速度可达每秒数 GB,其各级别的解码速度均为 LZ4 的 1.5–2.8 倍,且输出体积相等或更小。

<p><a href="https://lobste.rs/s/mf3tmv/zxc_lossless_compression_built_for_ultra">Comments</a></p>
Original Article
View Cached Full Text

Cached at: 10/14/26, 04:11 PM

# ZXC: Lossless compression built for ultra-fast decode Source: [https://libzxc.org/](https://libzxc.org/) ZXC is a lossless data compression library written in C, distributed as**libzxc**\. It is designed for data that is compressed once and read many times: firmware images, game assets, application bundles, and content delivered to many devices\. The encoder spends extra time up front so that decompression runs at several gigabytes per second on ARM and x86\. At every compression level ZXC decodes faster than LZ4, and produces output of equal or smaller size\. ZXC is free software, released under the[BSD 3\-Clause License](https://opensource.org/license/bsd-3-clause)\. It has no dependencies, and official bindings exist for Rust, Python, Node\.js and Go\. Development happens on[GitHub](https://github.com/hellobertrand/zxc)\. **The current release is ZXC 0\.15\.0**, released on 2026\-10\-13\. See the[changelog](https://libzxc.org/docs/changelog/)for what changed, and[Downloading ZXC](https://libzxc.org/#download)below\. Decompression speed against codecs of similar size Fast61\.76 % of original zxc \-113,513 MB/s lz4 \-\-fast \-175,609 MB/s **2\.41× faster**decode, smaller output \(61\.76 % vs 62\.15 %\) Default46\.65 % of original zxc \-39,707 MB/s lz44,774 MB/s **2\.03× faster**decode, smaller output \(46\.65 % vs 47\.60 %\) High36\.28 % of original zxc \-66,884 MB/s lz4hc \-94,522 MB/s **1\.52× faster**decode, smaller output \(36\.28 % vs 36\.75 %\) Ultra33\.09 % of original zxc \-75,054 MB/s zstd \-11,803 MB/s **2\.80× faster**decode, smaller output \(33\.09 % vs 34\.53 %\) Figure 1\. Single\-threaded decompression of`silesia\.tar`\(211\.9 MB\), measured with lzbench 2\.4\.1 and zxc 0\.15\.0\. ZXC levels 1, 3, 6 and 7 are each compared with the codec that produces output of similar size\.Apple M2, macOS 26, Clang 21, \-march=native\. Full results are in the[benchmark tables](https://libzxc.org/#benchmarks)\.## Specifications ## Why ZXC? LZ4 is symmetric: it compresses about as fast as it decompresses\. That suits logs and swap, but not data that is shipped\. A firmware image is compressed once on a build server and decompressed on every device that installs it, so time saved during compression helps nobody\. ZXC moves the work to the encoder\. Match selection, optimal parsing and statistics tuning are done once, and the bitstream is laid out for the pipelines and branch predictors of modern processors\. The decoder stays short, has few branches, and uses SIMD where it is available\. Typical uses: - Firmware and over\-the\-air updates\. In\-place decompression keeps peak memory close to the decompressed size\. - Game assets and application start\-up, where load time and battery use matter\. - Packaged artefacts and content delivery, where more original data is delivered per byte read from disk or network\. - Read\-heavy storage\. Seekable archives can decode any block without reading the blocks before it\. ## Features - **Seekable archives\.**An optional seek table gives O\(1\) random access to any block\. - **In\-place decompression\.**Decode inside a single buffer with about 1 % overhead instead of a second allocation\. - **Trained dictionaries\.**`zxc \-\-train`builds a dictionary for small, similar payloads such as JSON documents, log lines or RPC messages\. - **Multi\-threaded streaming\.**The file and stream interfaces split work across processor cores\. - **Hand\-written SIMD\.**SSE2, AVX2 and AVX\-512 with run\-time selection on x86; NEON on ARMv8 and later\. - **Portable\.**Tested on x86\_64, ARM64, ARMv7, ARMv6, RISC\-V, POWER, s390x and i386\. - **Careful interface\.**Every call takes an explicit output capacity\. The library is thread\-safe, with reusable contexts for tight loops and static contexts for targets without a heap\. - **Optional checksums\.**Per\-block integrity checks based on rapidhash\. - **Documented format\.**The[wire format](https://libzxc.org/docs/format/)\(version 9\) is specified in full, and public conformance vectors let others write independent decoders\. ## Compression levels Seven levels trade compression time for size\. Decompression stays in the multi\-GB/s range at every level\. Level 3 is the default\. Size is the compressed size as a percentage of`silesia\.tar`\. Speeds are single\-threaded on Apple M2 with lzbench 2\.4\.1\. Blocks are 512 KB by default; use`\-B 256K`for streaming or memory\-constrained targets\. ## Benchmarks ZXC is included in the two main open\-source compression benchmark suites,[lzbench](https://github.com/inikep/lzbench)and[TurboBench](https://github.com/powturbo/TurboBench), so the figures below can be reproduced with either tool alongside more than 70 other codecs\. Benchmarks also run on every commit on x86\_64 and ARM64 machines; see the[latest results](https://github.com/hellobertrand/zxc/actions/workflows/benchmark.yml)\. [![Compression ratio against decompression speed for ZXC, LZ4, Zstandard, LZAV, Snappy and zlib, with the Pareto frontier, one panel per processor: Apple M2, Google Axion, AMD EPYC 9B45 and AMD EPYC 7B13. Every ZXC level sits on the frontier.](https://libzxc.org/docs/images/bench-pareto-decompression.svg)](https://libzxc.org/docs/images/bench-pareto-decompression.svg)Figure 2\. Compression ratio of`silesia\.tar`against single\-threaded decompression speed \(logarithmic scale\), on two ARM64 and two x86\_64 processors; up and to the right is better\. From the[whitepaper](https://libzxc.org/docs/whitepaper/)\.The decoder's speed is paid for at compression time, and on this axis LZ4 and Zstandard are ahead\. Levels 1 and 2 still compress at several hundred MB/s; levels 6 and 7 run at about 10 MB/s, slower than`lz4hc \-9`, and are meant for data that is compressed once and read many times\. [![Compression ratio against compression speed, on a logarithmic scale, for ZXC, LZ4, Zstandard, LZAV, Snappy and zlib, with the Pareto frontier, one panel per processor: Apple M2, Google Axion, AMD EPYC 9B45 and AMD EPYC 7B13.](https://libzxc.org/docs/images/bench-pareto-compression.svg)](https://libzxc.org/docs/images/bench-pareto-compression.svg)Figure 3\. Compression ratio of`silesia\.tar`against single\-threaded compression speed \(logarithmic scale\), on the same four processors; up and to the right is better\. From the[whitepaper](https://libzxc.org/docs/whitepaper/)\.Raw decode speed leaves out half of the picture\. When the decoder is fed from a disk, a network or another core, the compressed bytes are what is scarce, and what matters is how much original data each compressed megabyte yields\. Effective throughput combines both: decode speed × 100 / ratio \(%\)\. On this measure every ZXC level is ahead of LZ4, on all four processors\. [![Effective throughput relative to LZ4 for every ZXC level and for LZ4, LZ4HC, LZAV, Zstandard and Snappy, on Apple M2, Google Axion, AMD EPYC 9B45 and AMD EPYC 7B13. All ZXC levels are above the LZ4 baseline of 1.00.](https://libzxc.org/docs/images/bench-effective.svg)](https://libzxc.org/docs/images/bench-effective.svg)Figure 4\. Effective throughput \(decode speed × 100 / ratio %\) relative to LZ4, on the same four processors; higher is better, and LZ4 is 1\.00\. From the[whitepaper](https://libzxc.org/docs/whitepaper/)\.Dividing the clock frequency by the decompression speed gives the cost of each decompressed byte in processor cycles, which compares processors running at different frequencies\. ZXC spends less than one cycle per byte at every level\. [![Processor cycles per decompressed byte for every ZXC level and for memcpy, LZ4, LZ4HC, LZAV, Snappy and Zstandard, on Apple M2, Google Axion, AMD EPYC 9B45 and AMD EPYC 7B13.](https://libzxc.org/docs/images/bench-cycles.svg)](https://libzxc.org/docs/images/bench-cycles.svg)Figure 5\. Processor cycles per decompressed byte \(clock frequency / decompression speed\), on the same four processors; lower is better\. From the[whitepaper](https://libzxc.org/docs/whitepaper/)\.**Apple M2**\(ARM64\)Apple M2, macOS 26, Clang 21, \-march=native\. Single thread, lzbench 2\.4\.1,`silesia\.tar`\. Speeds in MB/s; size as a percentage of the input\. **Google Axion**\(ARM64\)Google Axion \(Neoverse V2\), GCP C4A, GCC 14\.4, \-march=native\. Single thread, lzbench 2\.4\.1,`silesia\.tar`\. Speeds in MB/s; size as a percentage of the input\. **AMD EPYC 9B45**\(x86\_64\)AMD EPYC 9B45 \(Zen 5\), GCP C4D, GCC 14\.4, \-march=native\. Single thread, lzbench 2\.4\.1,`silesia\.tar`\. Speeds in MB/s; size as a percentage of the input\. **AMD EPYC 7B13**\(x86\_64\)AMD EPYC 7B13 \(Zen 3\), GCP C2D, GCC 14\.4, \-march=native\. Single thread, lzbench 2\.4\.1,`silesia\.tar`\. Speeds in MB/s; size as a percentage of the input\. ## Downloading ZXC Source and binary archives for Linux, macOS and Windows are published on the[releases page](https://github.com/hellobertrand/zxc/releases)\. Each archive carries SLSA build provenance, which you can check with: ``` gh attestation verify zxc-0.15.0-linux-x86_64.tar.gz --repo hellobertrand/zxc ``` ZXC is also packaged by distributions and package managers: Debian and Ubuntu``` sudo apt install zxc libzxc-dev ``` Homebrew``` brew install zxc ``` vcpkg``` vcpkg install zxc ``` Conan``` conan install -r conancenter --requires="zxc/[*]" --build=missing ``` Winget``` winget install hellobertrand.zxc ``` Which version each distribution currently ships is tracked by[Repology](https://repology.org/project/zxc/versions): [![Packaging status of ZXC across distributions and package managers, from Repology.](https://repology.org/badge/vertical-allrepos/zxc.svg)](https://repology.org/project/zxc/versions) To build from source you need CMake 3\.14 or later and a C17 compiler \(GCC, Clang or MSVC\): ``` git clone https://github.com/hellobertrand/zxc.git cd zxc cmake -B build -DCMAKE_BUILD_TYPE=Release cmake --build build --parallel sudo cmake --install build ``` The installation provides CMake \(`find\_package\(zxc\)`, target`zxc::zxc\_lib`\) and pkg\-config \(`libzxc`\) files\. Meson users can include ZXC as a subproject; see the[integration guide](https://libzxc.org/docs/install/)\. ## Quick start The`zxc`command reads and writes files or pipes, and can be used as a compressor by`tar`: ``` # Compress (level 3 by default), then decompress zxc -5 assets.tar assets.tar.zxc zxc -d assets.tar.zxc assets.tar # Seekable archive, for random access zxc -S big.bin big.bin.zxc # As a compressor for tar tar -I 'zxc -5' -cf data.tar.zxc data/ # Measure speed on your own machine zxc -b input_file ``` From C, the buffer interface compresses and decompresses in one call each: ``` #include "zxc.h" uint64_t bound = zxc_compress_bound(src_size); zxc_compress_opts_t c = { .level = ZXC_LEVEL_DEFAULT, .checksum_enabled = 1, }; int64_t csize = zxc_compress(src, src_size, dst, bound, &c); zxc_decompress_opts_t d = { .checksum_enabled = 1 }; int64_t n = zxc_decompress(dst, csize, out, out_cap, &d); if (n < 0) fprintf(stderr, "zxc: %s\n", zxc_error_name((int)n)); ``` See the[examples](https://libzxc.org/docs/examples/)for the streaming, context, seekable and dictionary interfaces, the[API reference](https://libzxc.org/docs/api/)for every function, and the[manual page](https://libzxc.org/docs/cli/)for all command options\. ## Language bindings The official bindings are maintained in the main repository and released with the library\. They are published as`zxc\-compress`, because the name`zxc`is taken on some registries\. Bindings maintained by others:[go\-zxc](https://github.com/meysam81/go-zxc)\(Go\),[zxc\-nim](https://github.com/openpeeps/zxc-nim)\(Nim\), and a[Free Pascal port](https://github.com/Xelitan/Free-Pascal-port-of-ZXC-compressor-decompressor)\. ## Testing - Fuzzed around the clock by Google[OSS\-Fuzz](https://github.com/google/oss-fuzz), with eight harnesses covering compression, decompression, the block API, in\-place decoding, streaming, seekable archives and dictionaries; they reach over 80 % of the library's lines \([coverage history](https://introspector.oss-fuzz.com/project-profile?project=zxc)\)\. - The same harnesses run under ClusterFuzzLite on every pull request\. - AddressSanitizer, UndefinedBehaviorSanitizer and Valgrind in continuous integration; Cppcheck, the Clang Static Analyzer and CodeQL on every change; continuous security analysis of the code and its dependencies by Snyk\. - Decoder conformance vectors and byte\-exact tests of the encoder output, so that the wire format cannot change by accident\. - Builds and tests across several operating systems, compilers and eight processor architectures\. - Pinned CI dependencies, tracked by the[OpenSSF Scorecard](https://scorecard.dev/viewer/?uri=github.com/hellobertrand/zxc)\. ## Getting help and contributing Questions and ideas are welcome in[GitHub Discussions](https://github.com/hellobertrand/zxc/discussions)\. Please report bugs on the[issue tracker](https://github.com/hellobertrand/zxc/issues), and security problems privately as described in the[security policy](https://github.com/hellobertrand/zxc/security/policy)\. Contributions are welcome; read the[contribution guidelines](https://github.com/hellobertrand/zxc/blob/main/.github/CONTRIBUTING.md)first\. You can also support the project through[GitHub Sponsors](https://github.com/sponsors/hellobertrand)\.

Similar Articles

OpenZL

Lobsters Hottest

OpenZL is a compression library that generates specialized compressors for specific data formats, achieving high compression ratios at high speeds suitable for datacenter workloads like AI processing.

Fc, a lossless compressor for floating-point streams

Hacker News Top

fc is an open-source lossless compressor for IEEE-754 64-bit double streams, offering superior compression ratios for structured data compared to zstd and fpzip, though with slower encoding speeds.