FAQ

Why is lha's decompress so much slower than deflate / zstd / lz4?

Short answer: the algorithm is fundamentally bit-serial and there's zero SIMD in the source. ~3-7× speedup is available with non-SIMD algorithmic changes; matching zstd -1 is a multi-year project.

The two hot paths in the source

Decoding LZHUF means:

• Read N bits → walk a binary tree (one branch per bit) → output one symbol. (src/huf.c:decode_c_dyn, src/huf.c:decode_p_dyn)
• If the symbol is a back-reference, copy L bytes from D bytes ago in the slide window. (src/slide.c's hand-rolled for loop, one byte per iteration.)

Why this is fundamentally slow

• Static Huffman means the bit-stream is decoded one bit at a time. The decoder can't "look ahead" more than 1-2 bits without doing the table walk anyway.
• No SIMD anywhere: grep -nE '(mmx|sse|avx|simd|__m128i|__builtin_ia32)' src/*.c returns zero hits. The vendored 1.14i code is straight ANSI C from 1995-2003, with no vectorization.
• Back-reference copy is byte-by-byte in src/slide.c. A memcpy(dst, src, len) call would already be 2-4× faster on modern glibc (which has SSE2/AVX2 memcpy internally).

What you can do without changing the on-disk format

Combined: 3-7× decode speedup, taking lha -lh5- from ~45 MB/s to ~150-300 MB/s on the kenlm corpus — competitive with deflate level 1-3 (~300-500 MB/s on the same corpus), but not "best in class."

Hard ceiling: what tANS buys (and doesn't)

To match zstd -1 (~2 GB/s) you'd need a fundamentally different entropy coder (tANS/FSE) and a faster LZ77. That means changing the on-disk format — see "Where should new formats live?" below. lha -lh5- on today's C decoder is the limit; no algorithmic trick within LZHUF gets above ~300 MB/s decode.

Source citation

The bench numbers come from a 5-run, kenlm upstream source (1.83 MiB / 304 files) bench, Apple M-series, native lha build. Full table on the perf page. The 5-axis source audit on the security page confirms the bit-loop and per-byte copy are the only two decode-side hot paths.

Could tANS make lha competitive with modern codecs?

Short answer: yes, with tANS, lha lands in the same league as deflate / brotli. Not in the same league as zstd -1+ (multi-year optimization gap) and not in the same league as lz4 / snappy (no entropy coder at all — different architecture).

Where tANS lands against each competitor

The fundamental limit

A decoder is bottlenecked by memory bandwidth + branch mispredicts + cache misses. tANS minimizes branch mispredicts (one branch per symbol). lz4 minimizes cache misses (literal copy in 16-byte chunks). Modern CPUs hit ~1 byte/cycle for the simplest decoders; tANS is around 1-2; lz4 is around 1. The architectures trade these two bottlenecks; one can't dominate the other from outside.

What lha's actual competitive position is

Adding tANS gives lha "competitive with deflate / brotli" status, not "beating zstd -1+" status, and definitely not "beating lz4" status. The real value of lha in 2026 is not speed — it's 35-year format stability + single-file static binary with no deps. Speed is the price of that. So the question becomes: do we add tANS as a new format (.lh8-) to give speed-conscious users an option, while keeping .lh5- as the stable read-only compatibility target? See "Where should new formats live?".

Is zstd -1 "the best" zstd level?

Short answer: yes, zstd -1 is the fastest zstd level (lowest compression ratio, highest speed). But it's not "best" in the sense of "best default" — that would be zstd -3.

zstd's level table

zstd uses zstd -N for levels 1-22, or zstd --fast=N for "faster than default."

Why -3 is the actual default

The speed/ratio curve is not linear:

• -1 to -3: very flat on the time axis, real gain on ratio. Going to -3 is a no-brainer.
• -3 to -10: roughly linear trade.
• -10 to -22: very flat on the ratio axis, big time cost. The ratio gains diminish.

Hence zstd's author (Yann Collet) chose -3 as the default: it's the shoulder of the curve. -1 is too aggressive on ratio for most use cases; -10 wastes time without much gain.

But zstd -1 isn't the fastest decoder overall

zstd -1 is the fastest zstd level, but:

lz4 / snappy are 1.5-2× faster than zstd -1 because they have no entropy coder at all. So "fastest decoder" is a two-track race, and lz4 wins the no-entropy track; zstd -1 wins the entropy-track.

What are lha's unique features vs bzip2 / zip / 7z?

Short answer: lha's "features" are mostly not features — they're trade-offs that bought a 35-year stable format. But lha has some genuine uniqueness: per-file independent compression, stdio-stream friendly, and streaming-buildable catalog.

What lha does not have

lha is a stream-oriented (not block) archiver — same shape as zip / gzip / tar, not bzip2 / 7z. So bzip2's "seek to byte 100 MB and decode 1 KB" is structurally impossible with lha -lh5-.

What lha does have that's unusual

• 35-year format stability. Files written in 1990 decode today. zip has 36+ years, tar has 45+, bzip2 28, 7z 25. lha isn't the longest but it's at the top tier.
• Streaming-buildable catalog. LHA headers are fixed-size (~35 B per file). You can read an lha archive in one pass, building an in-memory index of "file N at offset O, size S, mtime M" without decompressing any file. zip can't do this (central directory is at the end).
• Per-file independent compression. Each entry's compression method is in its own header. File 1 might be -lh0- (stored), file 2 -lh5-, file 3 -lh0- again. No "all files share one dictionary" constraint.
• stdio native. lha c dir/ > archive.lzh and lha xq archive.lzh < /dev/tty work directly. zip / 7z / tar need temp files for stdout.
• Tiny decompression code. LZHUF decoder is ~1,500 lines of C — much smaller than zstd's ~50,000 or 7z's ~30,000. Easier to embed in embedded systems, easier to audit (we just did 5-axis on it).
• No entropy table in the stream. Static Huffman means the table is in the decoder, not the data. A 50-byte file in lha has only the 35-byte header + 50-byte body, no per-block overhead. deflate has a ~20-byte tree per block.
• Japanese filename encodings (Shift-JIS, EUC-JP) baked in for legacy BBS / 2ch archives.

What this means strategically

lha's value proposition in 2026 is format stability + zero deps + tiny size + 35-year portability, not "rich feature set." To get bzip2-style features (random access, index, strong checksum) the right path is new formats .lh5b- (block), .lh8- (tANS), and .lhi- (index file) — not a Rust rewrite of lha. See next question.

Could a Rust rewrite help lha? (the lha-rs question)

Short answer: no. lha-rs is not worth it as a 1:1 Rust replacement of the C version. The honest answer: most of the standard reasons for a Rust rewrite don't apply to lha specifically.

Each standard "rewrite in Rust" reason, applied to lha

When a Rust rewrite is actually right

One of these conditions must hold:

• The C maintainer is retiring and the only next-generation maintainers are Rust developers — it's an exit strategy.
• A new format is designed Rust-first (uses async, Send plumbing, rayon parallelism, std SIMD for portable vectorization).
• A specific user requirement mandates it (e.g. "must run in WebAssembly in a browser extension" — Rust's wasm32-unknown-unknown is the only sane path).

None of these applies to lha today.

What the right move is

1. Stay in lha (C) — maintain and audit. 5-axis security audit done; libFuzzer integration 1-2 weeks away; oss-fuzz entry 1-2 hours. Done.
2. Add new formats in C as subdirectories: src/lh5b/ (block format with random read), src/lh8/ (tANS), src/lhi/ (index file). C implementations get the existing CI matrix; no new repo, no new release cadence.
3. Write a format spec at docs/lzh-format.md so any future implementation (Rust, Python, Go) has a single source of truth.
4. If new formats prove useful, then a separate ljh-sh/lha-spec (or similar) for multiple reference implementations in different languages. Not a "rewrite" repo — a multi-impl test-bed.

lha-rs is not on this list. It would be a 6-12-month project to rewrite a 13,400-line C program whose safety profile is already good, in a language whose value proposition doesn't help. Better: keep the C, do the small additional work in C, and reserve Rust for the day a new format genuinely needs it.

Where should new formats (.lh5b- / .lh8- / .lhi-) live?

Short answer: in the existing ljh-sh/lha repository, not in a new one. New formats are additions to the lha family, not replacements for it.

Proposed new formats

Where each lives

• src/lh5b/ — block format. C. Subdirectory of ljh-sh/lha. 4-6 weeks.
• src/lh8/ — tANS backend. C or Rust (tANS is a fresh format, so this is the place where if Rust is the right choice, this is the right place). 12-18 months. Likely still in C for consistency with the rest of lha.
• src/lhi/ — index format. C. 1-2 weeks.
• docs/lzh-format.md — format spec that the new formats all reference. 2-3 weeks.

Single binary that handles all of them

The killer feature of doing it in the existing repo: a single ljh-sh/lha binary that reads all of these formats:

$ lha l archive.lh5-          # canonical
$ lha l archive.lh5b         # block random-read
$ lha l archive.lh8-          # tANS, faster decode
$ lha l --index archive.lhi   # streamed catalog
$ lha x archive.lh8-          # write a new tANS archive

Single static binary, ~250 KB on disk, zero deps. The same x i lha / x eget use lha install path. 35-year stable read path + modern tANS write path + block random read. This is lha's competitive position in 2026: a single binary that does what no other archiver can do, and weighs 250 KB.