snappy-hs-0.1.2.0: README.md

# snappy-hs

A pure Haskell implementation of the Snappy compression format.

This library prioritizes portability and simplicity over raw speed. It works reliably across platforms without requiring a C toolchain or dealing with FFI.

## Performance

Measured against the native C library (the `snappy` bindings) on the Google Snappy
test corpus, GHC 9.12 / aarch64, library built with `-O2`:

| dataset (size)        | decompress vs C | compress vs C |
| --------------------- | --------------- | ------------- |
| html (100 KB)         | 1.8x            | 2.3x          |
| alice29.txt (149 KB)  | 1.5x            | 3.1x          |
| geo.protodata (116 KB)| 1.8x            | 2.4x          |
| urls.10K (686 KB)     | 2.1x            | 2.6x          |
| fireworks.jpeg (120 KB, incompressible) | 1.0x | 1.8x |

**Decompression runs at roughly C parity** (~1-2x) and compression is ~2-3x of C.
The gap that remains is GHC's native code generator versus a C compiler, not the
algorithm — the encoder mirrors C Snappy's `CompressFragment` (skip heuristic,
word-at-a-time match extension, input-sized hash table). Output is validated to be
byte-compatible with the C library in both directions.

Reproduce with `cabal bench` (criterion, needs the C `snappy` library installed)
or `cabal run snappy-bench` (pure, no C dependency).

## When to use

* You want **cross-platform Snappy encode/decode** with a **pure Haskell** dependency stack
* You’d rather avoid **C FFI** and the build/packaging complexity that comes with it

## When not to use

* You need **maximum throughput** (use the native library or an FFI-based binding instead).
  You would get a lot of mileage from the library too however.