X-Lex™ vs gzip / zstd / xz

Next-Generation Core Compression Technology

Measurement date: 7 September 2026 · AC power
Machine: HP EliteBook 735 G6 · AMD Ryzen 5 PRO 3500U (4 cores / 8 threads) · Radeon Vega · 21 GiB RAM · Ubuntu 24.04 · Linux 6.17 x86_64
X-Lex™ build: Core package xlex_core_20260906 (licensed rows) · OEM Eval for inputs ≤ 2 MiB
Source run: lab comparison X_AEGIS_netti_vertailu_ajat_20260907T112219 (sizes + times, one session)

How to read this page

Compressed sizes: Reproducible claim. Same zip + same input → same byte counts on other machines.

Encode / decode times: Indicative only (this laptop, moderate load). Not a guarantee or SLA. Measure on your server — many hosts are faster than these examples.

OEM Eval (free): always one thread; max 2 MiB per call. Use it to try the method on small files.
Licensed Core: full table. Rows marked † exceed the OEM Eval limit and use licensed X-Lex™.
One-thread rows: X-Lex™ encode with 1 thread; zstd -T1; gzip single-thread; xz -T1.
Multi-thread rows: licensed X-Lex™ with four threads (not all eight logical CPUs); zstd -T4. Compressed size matches one-thread X-Lex™.
Codecs: X-Lex™ OEM Eval / licensed Core · zstd 1.5.x · gzip 1.12 · xz 5.4.x.
X-Lex™ may use zlib on an internal stream when that stream is smaller. That is not a .gz file and not an add-on.
Corpus: real-world NDJSON log samples, structural XML, and text (not synthetic JSON documents).
Timing: CLI wall clock (xaegis-pack, zstd, gzip, xz) · warmup + median of five. Smaller is better.

All listed inputs round-trip bit-identically. There is no lossy mode in these rows.

Headline (honest)

On real-world NDJSON observations log slices, X-Lex™ delivers the smallest compressed size among X-Lex™, zstd-3, zstd-9, gzip-9, and xz-6.

Example — 32 MiB NDJSON observations: X-Lex™ 89,909 B (~373× vs uncompressed; about 3.1× smaller than zstd-3 at 281,939 B).

Speed: zstd-3 is usually faster to encode. On decode, X-Lex™ product multi-thread is competitive and often ahead on these observation slices; on some other files (e.g. mixed logs) zstd remains faster. Times below are examples from one machine — verify on yours.

1. Compressed output size (bytes)

Input Corpus	Original	X-Lex™	zstd-3	zstd-9	gzip-9	xz-6
Text 871 B	871 B	446 B	480 B	474 B	469 B	556 B
NDJSON repetitive 1 MiB	1,048,494 B	2,471 B	38,784 B	47,890 B	107,357 B	33,464 B
XML 1 MiB	1,048,550 B	19,422 B	45,576 B	45,566 B	73,428 B	32,928 B
NDJSON reflect_decision †	3,819,463 B	139,168 B	321,365 B	281,558 B	297,268 B	231,832 B
NDJSON execution_log †	8,467,276 B	430,200 B	796,346 B	698,742 B	740,180 B	610,620 B
NDJSON observations 8 MiB †	8,388,608 B	18,717 B	43,913 B	30,521 B	88,952 B	34,100 B
NDJSON observations 16 MiB †	16,777,216 B	39,221 B	90,500 B	62,480 B	200,282 B	66,116 B
NDJSON observations 32 MiB †	33,554,432 B	89,909 B	281,939 B	227,910 B	504,065 B	227,156 B

† Exceeds OEM Eval limit (2 MiB/call) — licensed Core.

2. Encode time (ms) — one thread (indicative)

Same corpus as the size table. CLI. Measure on your machine.

Input Corpus	X-Lex™	zstd-3	zstd-9	gzip-9	xz-6
Text 871 B	24	6	9	11	12
NDJSON repetitive 1 MiB	80	14	46	43	535
XML 1 MiB	92	14	39	35	417
NDJSON reflect_decision †	84	28	98	99	883
NDJSON execution_log †	158	63	195	234	1405
NDJSON observations 8 MiB †	63	32	52	77	487
NDJSON observations 16 MiB †	101	32	71	143	976
NDJSON observations 32 MiB †	166	60	168	339	2112

3. Decode time (ms) — indicative

X-Lex™ = product multi-thread decode. Others = one thread (-T1 / single-thread gzip / xz). Same session as encode.

Input Corpus	X-Lex™	zstd-3	zstd-9	gzip-9	xz-6
Text 871 B	10	8	8	9	10
NDJSON repetitive 1 MiB	16	11	10	15	16
XML 1 MiB	14	15	13	14	18
NDJSON reflect_decision †	24	17	19	31	44
NDJSON execution_log †	39	25	24	54	96
NDJSON observations 8 MiB †	18	20	29	45	40
NDJSON observations 16 MiB †	28	30	36	73	57
NDJSON observations 32 MiB †	38	51	57	134	98

Note: On observation slices (8–32 MiB), X-Lex™ decode is ahead of zstd-3 in this run. On several other files, zstd is faster. Density leadership and decode leadership are not the same claim.

4. Multi-thread encode / decode (ms) — ~4 threads (indicative)

Licensed X-Lex™ · zstd -T4. Same session. xz omitted here (no practical multi-thread CLI in this run).

Encode multi-thread

Input Corpus	X-Lex™	zstd-3	zstd-9
Text 871 B	24	7	9
NDJSON repetitive 1 MiB	72	12	40
XML 1 MiB	110	14	40
NDJSON reflect_decision †	64	28	99
NDJSON execution_log †	120	57	193
NDJSON observations 8 MiB †	58	23	43
NDJSON observations 16 MiB †	99	31	75
NDJSON observations 32 MiB †	172	58	142

Decode multi-thread

Input Corpus	X-Lex™	zstd-3	zstd-9
Text 871 B	10	6	9
NDJSON repetitive 1 MiB	17	10	9
XML 1 MiB	13	9	8
NDJSON reflect_decision †	25	16	18
NDJSON execution_log †	40	21	25
NDJSON observations 8 MiB †	18	19	30
NDJSON observations 16 MiB †	27	38	31
NDJSON observations 32 MiB †	37	54	54

Key takeaways (aligned with the numbers)

Density first. On NDJSON observations 32 MiB, X-Lex™ is ~3.1× smaller than zstd-3 (89,909 B vs 281,939 B) and smaller than zstd-9 / gzip-9 / xz-6 in this table.
Encode speed. zstd-3 usually wins raw encode time. X-Lex™ still encodes far faster than xz-6 on large rows (example: 166 ms vs ~2112 ms at 32 MiB, one thread) — indicative.
Decode. On observation slices, X-Lex™ multi-thread decode is strong vs zstd in this run. It is not "fastest on every file."
OEM vs Core. Try OEM Eval on ≤2 MiB inputs. Reproduce the † rows with licensed Core.
Your machine wins the argument. Publish sizes as the hard claim; treat all milliseconds as examples and re-measure on the customer host.