Benchmark: fflate vs lz-string vs shorty with long string

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()

for (let x = 0; x < 5; x++) {
    string = string + string;
}

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 dive into the world of JavaScript microbenchmarks and explore what's tested in this specific benchmark.

**Benchmark Overview**

The provided JSON represents a benchmark that compares the performance of three different compression algorithms: fflate, lz-string, and shorty. The test case uses a long string as input, which is then compressed and decompressed multiple times to measure the performance of each algorithm.

**Compression Algorithms**

Here's a brief overview of each compression algorithm:

1. **FFlate**: A fast and lightweight compression library that supports various algorithms, including LZMA, LZ4, and Snappy. It's designed for general-purpose data compression.
2. **Lz-string**: A simple and efficient compression algorithm that converts strings to UTF-16 format using a dictionary-based approach.
3. **Shorty**: A lightweight compression library that uses a combination of techniques, including Huffman coding and delta encoding, to compress data.

**Options Comparison**

The benchmark compares the performance of each algorithm with varying levels of memory allocation (mem) parameter:

* fflate: `level` (compression level) is fixed at 6, while `mem` ranges from 0 to 12.
* lz-string: The compression algorithm uses a fixed dictionary size and no variable `mem`.
* shorty: The algorithm uses a variable `mem` that can be adjusted.

**Pros and Cons**

Here are some pros and cons of each approach:

1. **FFlate**:
	* Pros: Fast, lightweight, supports various algorithms.
	* Cons: May not perform well on small input sizes or with low memory constraints.
2. **Lz-string**:
	* Pros: Simple, efficient, and fast for short strings.
	* Cons: Limited flexibility and performance may degrade with large input sizes.
3. **Shorty**:
	* Pros: Lightweight, flexible compression algorithm that adapts to input size.
	* Cons: May not be as fast as other algorithms, especially with high memory usage.

**Benchmark Results**

The provided benchmark results show the execution frequency per second for each test case:

1. **FFlate**: Higher performance in both compression and decompression phases.
2. **Lz-string**: Lower performance in compression phase but comparable to fflate in decompression phase.
3. **Shorty**: Lower performance overall, especially in compression phase.

**Conclusion**

The benchmark highlights the importance of choosing the right compression algorithm for a specific use case, considering factors like input size, memory constraints, and desired performance. While each algorithm has its strengths and weaknesses, fflate appears to be a strong contender due to its balanced performance and flexibility.

Latest run results:

Run details: (Test run date: 6 months ago)

User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36

Browser/OS: Chrome 124 on Mac OS X 10.15.7

View result in a separate tab

Test name	Executions per second
compress fflate	3054.2 Ops/sec
compress lz-string	603.4 Ops/sec
compress shorty	271.2 Ops/sec
decompress lz-string	2303.2 Ops/sec
decompress shorty	265.8 Ops/sec
decompress fflate	40735.5 Ops/sec

Related benchmarks:

fflate vs lz-string vs shorty with long string (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: 6 months 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):