Same lz4 wire. Memory-safe. Faster.
A memory-safe, SIMD-first LZ4 codec. Byte-for-byte LZ4 block + .lz4 frame compatible - every block and frame it emits decodes through the official C lz4, and it decodes anything lz4 produces. Faster than liblz4 on decode, encode, and LZ4HC across the corpus - at compressed sizes within ±0.01% of liblz4 on every domain. On x86-64 and Apple Silicon.
Drop-in for liblz4 (official C LZ4). SIMD backends: AVX2, NEON. An ABI-level shim exports the LZ4_* / LZ4F_* symbols numcodecs/Zarr, GDAL, and C/C++ consumers import - replace the system liblz4 binary, no recompile.
Headline
Faster on decode, encode, and LZ4HC - at equal size.
Stated plainly, because honest benchmarks are the whole point: across the full Bitruvius imagery corpus (8 GiB, 9 data-type domains), TurboLZ4 fast-encodes faster than the official C lz4 on 26 of 27 fixtures, decodes faster on 17 of 27, and runs LZ4HC faster on 22 of 27 - while its compressed output matches liblz4 to within ±0.01% on every single domain (and is fractionally smaller overall). An earlier version of this page showed larger decode multiples; those predated a fairness fix in our own benchmark harness - liblz4's timed region was carrying an allocation cost ours didn't. These are the fair numbers. The win column still differs by data type; find yours in the per-domain chart below.
fixtures encode faster than liblz4 (1.15× corpus average) - including the highly compressible optical and AI-inference domains where liblz4 used to lead.
corpus average vs liblz4 (up to 1.57× on elevation rasters), via a backend-agnostic wild-copy loop - decode is memory-bound, so scalar ≈ NEON ≈ AVX2.
vs liblz4 on every domain - dead parity, fractionally smaller overall. Faster with zero size cost, including LZ4HC levels 1-12 (level 12 matches liblz4's best ratio exactly, faster).
Every block, frame, and streamed frame round-trips byte-exact through the official C lz4 - both directions, AVX2 and NEON, continuously fuzz-tested.
Per-domain - x86_64 / AVX2
The win column, by data type.
Speed as a multiple of the official C lz4 on the same fixtures - decode, fast-encode, and LZ4HC. The dashed line is parity (1.0×); bars past it mean TurboLZ4 is faster. The Δsize column is our compressed output vs liblz4 (− = smaller). The soft cells we don't bury: SAR-quicklook decode and SAR-video LZ4HC trail liblz4 on these large fixtures - everything else wins or ties.
Block path; frame and streaming reuse the same kernels. Measured on the Bitruvius corpus, standard release build, three largest fixtures per domain.
Apple Silicon / NEON
Same story on ARM.
TurboLZ4's NEON backend is measured head-to-head against the official C lz4 on Apple M-series hardware, across a 320-sample imagery tile corpus at every block setting - default, acceleration 3 and 9, and LZ4HC levels 1 through 12.
Median decode beats liblz4 at all block settings (1.01-1.18×), with the same byte-exact wire compatibility validated on aarch64 every run.
Compressed output matches liblz4's at the default, acceleration, and HC-12 settings exactly (+0.00% medians); the rest sit within +0.4%.
The Apple-Silicon library ships profile-guided and CPU-tuned - the upstream C library ships generic builds. The drop-in is tuned for the machine it runs on.
Per-domain NEON bars (matching the x86-64 chart above) land from the M-series fixture sweep. High-compression encode on M-series currently trails liblz4 on some settings - the one open column, stated plainly.
A library swap. Not a migration.
- - Drop-in C ABI. The shim exports the exact LZ4_* and LZ4F_* symbols (block, frame, one-shot and streaming, HC) plus a ready-to-use C header. Point your loader at it - GDAL, numcodecs/Zarr, and C/C++ consumers link unchanged. Verified end-to-end by a real C program that links the library.
- - Free, dependency-free decoder. The decode path builds with no license check and no proprietary dependencies - freely redistributable. The encoder is the licensed half.
- - No size trade. At all. Compressed output matches liblz4 to within ±0.01% on every domain and is fractionally smaller in aggregate. The match-finder now includes lazy boundary search and, at LZ4HC levels 10-12, an optimal-parse stage - level 12 matches liblz4's best ratio exactly, faster.
Byte-exact on the wire.
- - Clean-room from the LZ4 block + frame spec. Every block, .lz4 frame, streamed frame, and LZ4HC block TurboLZ4 emits decodes byte-for-byte through the reference C lz4 - validated every CI run, on x86_64 and aarch64.
- - And the reverse: TurboLZ4 decodes everything the official lz4 and lz4_flex produce, across an edge-case battery, a fuzz/property suite, and the full imagery corpus.
LZ4 was created by Yann Collet; the liblz4 library is published under a BSD-2-Clause license, and lz4_flex is an open-source implementation. These names are used solely to identify the products and formats being compared; no affiliation, sponsorship, or endorsement is implied. TurboLZ4 is an independent, clean-room implementation of the openly published LZ4 block and frame formats — interoperability claims are verified by our test suites. Performance comparisons reflect our own measurements under the stated methodology; results vary by workload and hardware. Full third-party notices: Attributions.