vs brotli
Brotli is Google’s successor to gzip, optimized for web transport. It has a larger window than DEFLATE and ships with a static dictionary of common web strings. It’s excellent at what it targets; Bindu targets different problems.
- Brotli: LZ77 variant with a 16 MB window, second-order context modeling, and a 119 KB built-in dictionary biased toward HTML/CSS/JS/English text.
- Bindu: symbolic pipeline. Symbols are computed on the spot for the data in front of it, not pulled from a fixed dictionary.
Ratio (measured)
Section titled “Ratio (measured)”From the industry benchmark — Brotli ran on the 14 Silesia/Hutter text files where it applies:
| Aggregate | Brotli | Bindu |
|---|---|---|
| Files compressed (% reduction) | 74.54% | 77.95% |
Selected per-file ratios:
| Workload | Brotli -11 | Bindu |
|---|---|---|
Silesia webster | 4.92× | 5.75× |
Silesia xml | 12.41× | 12.63× |
Silesia nci | 22.08× | 24.79× |
| Hutter enwik8 | 3.88× | 4.29× |
| Hutter enwik9 (1 GB) | 3.87× | 5.43× |
Brotli’s static dictionary gives it a head start on small web-style payloads. On larger files, Bindu’s symbol table catches and surpasses it.
Brotli at level 11 is very slow to encode. Bindu’s encode throughput is comparable on text, faster on structured data once the symbolic pipeline strips redundancy upstream of the entropy stage.
When brotli wins
Section titled “When brotli wins”- HTTP content-encoding: browsers decode brotli natively. Nothing decodes Bindu natively in a browser.
- Small text payloads where shipping any kind of dictionary or symbol table costs more than it saves.
When Bindu wins
Section titled “When Bindu wins”- Sequential telemetry / satellite — see the flagship use case.
- Large structured archives (logs, JSON/CSV, code).
- Anywhere you want to query, search, or operate on the compressed form.