Benchmark: fflate vs lz-string vs shorty

HTML Preparation code:

<script src="https://unpkg.com/fflate@0.8.0"></script>
<script src="https://cdn.jsdelivr.net/npm/fflate@0.8.0/umd/index.js"></script>

<script src="https://enkimute.github.io/res/shorty.min.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/lz-string/1.5.0/lz-string.min.js"></script>

Script Preparation code:

var string = `[{"position":[0.4053397288042788,0.9161322508717471],"alias":"player11"}, {"position":[0.032885732668610945,0.5217127089309777],"alias":"player11"}, {"position":[0.046501222070234105,0.4416303631871801],"alias":"player11"}, {"position":[0.501956817885332,0.26260992265552496],"alias":"player11"}, {"position":[0.3972093640290386,0.2237804084367898],"alias":"player11"}, {"position":[0.4171841396793452,0.7250318425335418],"alias":"player11"}, {"position":[0.10370657307033793,0.8338842943449913],"alias":"player11"}, {"position":[0.760216361566781,0.4391116386058227],"alias":"player11"}, {"position":[0.31942962258914376,0.3931480967639178],"alias":"player11"}]`;
var shorty = new Shorty()
var buf = fflate.strToU8(string);

var fflateCompressed = fflate.compressSync(buf, { level: 6, mem: 8 });
var lzStringCompressed = LZString.compressToUTF16(string);
var shortyCompressed = shorty.deflate(string)

Tests:

compress fflate
// The default compression method is gzip // Increasing mem may increase performance at the cost of memory // The mem ranges from 0 to 12, where 4 is the default fflate.compressSync(buf, { level: 6, mem: 8 });
compress lz-string
LZString.compressToUTF16(string);
compress shorty
shorty.deflate(string)
decompress lz-string
LZString.decompressFromUTF16(lzStringCompressed);
decompress shorty
shorty.inflate(shortyCompressed)
decompress fflate
fflate.decompressSync(fflateCompressed);

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
compress fflate
compress lz-string
compress shorty
decompress lz-string
decompress shorty
decompress fflate

Fastest: N/A

Slowest: N/A

Autogenerated LLM Summary (model llama3.2:3b, generated one month ago):

LLMs can make mistakes. Check important info.

Let's break down the benchmark and explain what is being tested.

**Benchmark Overview**

The benchmark measures the performance of three compression libraries: `fflate`, `lz-string`, and `shorty`. The test cases include both compression and decompression operations.

**Compression Algorithms**

1. **`fflate`**: A fast and efficient compression library that uses LZ77, a dictionary-based compression algorithm.
2. **`lz-string`**: A JavaScript implementation of the LZ-String compression algorithm, which is similar to Gzip but more optimized for web use cases.
3. **`shorty`**: A lightweight, open-source compression library developed by Evan Hahn. It uses a combination of Huffman coding and LZ77-like algorithms.

**Compression Options**

For `fflate`, the benchmark tests different compression levels (from 0 to 9) with varying amounts of memory allocation (`mem`). This allows testing the trade-off between performance and memory usage.

For `lz-string`, the benchmark tests the compression algorithm without any additional options, as specified in the benchmark definition.

For `shorty`, the benchmark uses the default compression settings provided by the library.

**Pros and Cons**

* **`fflate`**:
	+ Pros: High compression ratios, fast decompression.
	+ Cons: Requires more memory for higher compression levels.
* **`lz-string`**:
	+ Pros: Fast compression, suitable for web use cases.
	+ Cons: May not be as efficient as `fflate` or `shorty`.
* **`shorty`**:
	+ Pros: Lightweight, easy to use, fast compression and decompression.
	+ Cons: May not match the performance of `fflate` or `lz-string`.

**Library Descriptions**

1. **`LZString`**: A JavaScript library for LZ-String compression and decompression. It's optimized for web use cases and provides a simple API for compression and decompression.
2. **`Shorty`**: A lightweight, open-source compression library developed by Evan Hahn. It uses a combination of Huffman coding and LZ77-like algorithms to achieve fast compression and decompression.

**Special Notes**

The benchmark uses Chrome 129 as the browser, which is an older version that may not be supported by all systems. The benchmark also skips any preamble or introductory content, as requested.

By running this benchmark, you can compare the performance of these three compression libraries in terms of compression ratio, decompression speed, and memory usage. This can help you choose the most suitable library for your specific use case.

Latest run results:

Run details: (Test run date: 20 hours ago)

User agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36

Browser/OS: Chrome 131 on Windows

View result in a separate tab

Test name	Executions per second
compress fflate	3096.8 Ops/sec
compress lz-string	6090.2 Ops/sec
compress shorty	3163.9 Ops/sec
decompress lz-string	15337.2 Ops/sec
decompress shorty	3225.2 Ops/sec
decompress fflate	59836.8 Ops/sec

Related benchmarks:

fflate vs lz-string vs shorty (version: 0)

emulate file compression/decompression

Comparing performance of: compress fflate vs compress lz-string vs compress shorty vs decompress lz-string vs decompress shorty vs decompress fflate

Created: one year ago by: Guest

Jump to the latest result

compress fflate

compress lz-string

compress shorty

decompress lz-string

decompress shorty

decompress fflate

Suite status: <idle, ready to run>

Experimental features:

Fastest: N/A

Slowest: N/A

Autogenerated LLM Summary (model llama3.2:3b, generated one month ago):