Thank you for the feedback! The results are indeed interesting. I am a little surprised that peak performance seems to be almost reached when maxWorkers is equal to 4.

For your information, here are the results on my M2.

20 x 20MiB level=5 useWebWorkers=false maxWorkers= 1: zip=15.97s
20 x 20MiB level=5 useWebWorkers=false maxWorkers= 2: zip=15.91s
20 x 20MiB level=5 useWebWorkers=false maxWorkers= 4: zip=15.82s
20 x 20MiB level=5 useWebWorkers=false maxWorkers= 8: zip=15.96s
20 x 20MiB level=5 useWebWorkers=false maxWorkers=16: zip=16.22s

20 x 20MiB level=5 useWebWorkers=true  maxWorkers= 1: zip=15.45s
20 x 20MiB level=5 useWebWorkers=true  maxWorkers= 2: zip=8.18s
20 x 20MiB level=5 useWebWorkers=true  maxWorkers= 4: zip=4.56s
20 x 20MiB level=5 useWebWorkers=true  maxWorkers= 8: zip=3.55s
20 x 20MiB level=5 useWebWorkers=true  maxWorkers=16: zip=3.81s

20 x 20MiB level=6 useWebWorkers=false maxWorkers= 1: zip=10.59s
20 x 20MiB level=6 useWebWorkers=false maxWorkers= 2: zip=6.74s
20 x 20MiB level=6 useWebWorkers=false maxWorkers= 4: zip=4.71s
20 x 20MiB level=6 useWebWorkers=false maxWorkers= 8: zip=4.82s
20 x 20MiB level=6 useWebWorkers=false maxWorkers=16: zip=4.51s

20 x 20MiB level=6 useWebWorkers=true  maxWorkers= 1: zip=9.21s
20 x 20MiB level=6 useWebWorkers=true  maxWorkers= 2: zip=4.93s
20 x 20MiB level=6 useWebWorkers=true  maxWorkers= 4: zip=3.20s
20 x 20MiB level=6 useWebWorkers=true  maxWorkers= 8: zip=4.04s
20 x 20MiB level=6 useWebWorkers=true  maxWorkers=16: zip=3.19s

Interestingly, results are still a bit better with maxWorkers set to 16 and native compression (level=6) on a CPU with 4+4 cores.

EDIT: When running the test multiple times, I see that the perf is actually worse with maxWorkers set to 16 most of the time, which is expected on my machine.

In the next weeks, I'll try to setup more perf tests, I'd like to

• measure (even coarsly) peak mem usage, important when doing stuff in parallel (we were using fflate but its lack of maxWorkers caused out-of-mem issues)
• use json inputs instead of random bytes
• try keepOrder and add entries sorted by increasing/decreasing byteLength
• undertand why maxWorkers has an impact on level6_NativeCompressionStream+useWebWorkers=false
• try different entryCount/entrySize
• maybe compare with pako,jszip,fflate
• generate all these numbers for chrome and firefox
• ...

I'll keep you posted if I find something interesting

Feel free to keep me posted, I think it will be interesting. I've focused more on robustness than performance, although I do pay some attention to it. Note that you can test the pure JS (no WASM) version, see ./index-native.js. I would recommend testing some code relying on Web Streams as well (instead of *Reader/*Writer classes). On that note, you should be able to easily test the fflate coder/decoder in zip.js by integrating this polyfill: https://www.npmjs.com/package/compression-streams-polyfill.

Regarding the "level6_NativeCompressionStream+useWebWorkers=false" case, zip.js always tries to compress multiple entries in parallel when maxWorkers > 1 even if web workers are disabled. The gain comes from the fact that each native CompressionStream instance runs on a separate thread (unlike the WASM module) and does not block the main thread. Consequently, in this case, the main thread spends most of its time calculating CRCs. BTW, Providing a native implementation for computing CRCs (i.e. crc32.js) would also improve perfs, generally speaking (it does not exist in browers). It could rely on zlib.crc32() for example, see https://nodejs.org/api/zlib.html#zlibcrc32data-value.

One thing I did not understand at first was that maxWorkers means "how many streams are processed concurrently", and that is independently of useWebWorkers.

So when useCompressionStream=true useWebWorkers=false the level of parallelism we get comes from the native CompressionStream implementation.

On NODEJS

• "All zlib APIs, except those that are explicitly synchronous, use the Node.js internal threadpool. This can lead to surprising effects and performance limitations in some applications". see nodejs doc
• UV_THREADPOOL_SIZE default is 4 (at least on my setup)

and indeed when changing UV_THREADPOOL_SIZE, we get different results

tested on 8 cores, 16 logical cores CPU:

UV_THREADPOOL_SIZE=1

> cd ./tests-perf && UV_THREADPOOL_SIZE=1 node ./node-runner.js
20 x 20MiB useCompressionStream=true  useWebWorkers=false maxWorkers= 1: zip=14.10s
20 x 20MiB useCompressionStream=true  useWebWorkers=false maxWorkers= 2: zip=12.84s
20 x 20MiB useCompressionStream=true  useWebWorkers=false maxWorkers= 4: zip=12.89s
20 x 20MiB useCompressionStream=true  useWebWorkers=false maxWorkers= 8: zip=13.07s
20 x 20MiB useCompressionStream=true  useWebWorkers=false maxWorkers=16: zip=13.50s

UV_THREADPOOL_SIZE=2

> cd ./tests-perf && UV_THREADPOOL_SIZE=2 node ./node-runner.js
20 x 20MiB useCompressionStream=true  useWebWorkers=false maxWorkers= 1: zip=14.21s
20 x 20MiB useCompressionStream=true  useWebWorkers=false maxWorkers= 2: zip=8.89s
20 x 20MiB useCompressionStream=true  useWebWorkers=false maxWorkers= 4: zip=8.18s
20 x 20MiB useCompressionStream=true  useWebWorkers=false maxWorkers= 8: zip=8.33s
20 x 20MiB useCompressionStream=true  useWebWorkers=false maxWorkers=16: zip=8.84s

UV_THREADPOOL_SIZE=4 (default)

> cd ./tests-perf && UV_THREADPOOL_SIZE=4 node ./node-runner.js
20 x 20MiB useCompressionStream=true  useWebWorkers=false maxWorkers= 1: zip=14.23s
20 x 20MiB useCompressionStream=true  useWebWorkers=false maxWorkers= 2: zip=8.94s
20 x 20MiB useCompressionStream=true  useWebWorkers=false maxWorkers= 4: zip=6.40s
20 x 20MiB useCompressionStream=true  useWebWorkers=false maxWorkers= 8: zip=6.18s
20 x 20MiB useCompressionStream=true  useWebWorkers=false maxWorkers=16: zip=6.60s

UV_THREADPOOL_SIZE=8

using UV_THREADPOOL_SIZE > 4 is not faster, not sure why...

> cd ./tests-perf && UV_THREADPOOL_SIZE=8 node  ./node-runner.js
20 x 20MiB useCompressionStream=true  useWebWorkers=false maxWorkers= 1: zip=15.87s
20 x 20MiB useCompressionStream=true  useWebWorkers=false maxWorkers= 2: zip=10.67s
20 x 20MiB useCompressionStream=true  useWebWorkers=false maxWorkers= 4: zip=7.42s
20 x 20MiB useCompressionStream=true  useWebWorkers=false maxWorkers= 8: zip=6.32s
20 x 20MiB useCompressionStream=true  useWebWorkers=false maxWorkers=16: zip=6.84s

on BROWSER

It seems there is no "builtin" parallelism in the native CompressionStream:

CHROME

20 x 20MiB useCompressionStream=true useWebWorkers=false maxWorkers= 1: zip=11.35s
20 x 20MiB useCompressionStream=true useWebWorkers=false maxWorkers= 2: zip=11.65s
20 x 20MiB useCompressionStream=true useWebWorkers=false maxWorkers= 4: zip=11.62s
20 x 20MiB useCompressionStream=true useWebWorkers=false maxWorkers= 8: zip=11.58s
20 x 20MiB useCompressionStream=true useWebWorkers=false maxWorkers=16: zip=11.66s

FIREFOX

20 x 20MiB useCompressionStream=true useWebWorkers=false maxWorkers= 1: zip=18.45s
20 x 20MiB useCompressionStream=true useWebWorkers=false maxWorkers= 2: zip=20.30s
20 x 20MiB useCompressionStream=true useWebWorkers=false maxWorkers= 4: zip=19.57s
20 x 20MiB useCompressionStream=true useWebWorkers=false maxWorkers= 8: zip=19.55s
20 x 20MiB useCompressionStream=true useWebWorkers=false maxWorkers=16: zip=19.72s

Hi, I did some additional tests in different CLI runtimes. Unsurprisingly Bun is the fastest. Surprisingly in Deno it looks like the CompressionStream API does not really support chunked data, it produces larger payloads (than the input file) with 64KB chunk size.

All the content below has been created with the help of "Gemini 3 Flash" in VSCode Copilot. The script generates a CSV file and a MD file. Jump to the end of the post for the conclusion.

Runner run-all-benchmarks.sh

#!/bin/bash

# Cleanup previous results
rm -f benchmark-results-node.csv benchmark-results-deno.csv benchmark-results-bun.csv benchmark-results-all.csv

echo "Running benchmark in Node.js..."
node benchmark-parallel.js

echo "Running benchmark in Deno..."
deno run --allow-all benchmark-parallel.js

echo "Running benchmark in Bun..."
bun run benchmark-parallel.js

# Create combined CSV
# Start with the header from the first file
# Create combined CSV
FIRST_FILE=""
[ -f benchmark-results-node.csv ] && FIRST_FILE="benchmark-results-node.csv"
[ -z "$FIRST_FILE" ] && [ -f benchmark-results-deno.csv ] && FIRST_FILE="benchmark-results-deno.csv"
[ -z "$FIRST_FILE" ] && [ -f benchmark-results-bun.csv ] && FIRST_FILE="benchmark-results-bun.csv"

if [ -n "$FIRST_FILE" ]; then
    head -n 1 "$FIRST_FILE" > benchmark-results-all.csv
    [ -f benchmark-results-node.csv ] && tail -n +2 benchmark-results-node.csv >> benchmark-results-all.csv
    [ -f benchmark-results-deno.csv ] && tail -n +2 benchmark-results-deno.csv >> benchmark-results-all.csv
    [ -f benchmark-results-bun.csv ] && tail -n +2 benchmark-results-bun.csv >> benchmark-results-all.csv
fi

# Generate Markdown table
MD_FILE="benchmark-results.md"
echo "# Zip.js Parallel Compression Benchmark Results" > "$MD_FILE"
echo "" >> "$MD_FILE"
echo "| Env | Lvl | UseCS | UseWW | MaxWorkers | Chunk | Time(ms) | Ratio(%) |" >> "$MD_FILE"
echo "| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- |" >> "$MD_FILE"

if [ -f benchmark-results-all.csv ]; then
    tail -n +2 benchmark-results-all.csv | while IFS=',' read -r env level usecs useww workers chunk time ratio; do
        echo "| $env | $level | $usecs | $useww | $workers | $chunk | $time | $ratio |" >> "$MD_FILE"
    done
fi

echo ""
echo "All benchmarks completed."
echo "Combined results available in benchmark-results-all.csv"
echo "Markdown table generated in $MD_FILE"

Test file benchmark-parallel.js used by the runner

import * as zip from "index.js";

// Node.js web-worker polyfill
if (typeof process !== "undefined" && process.versions && process.versions.node && !globalThis.Worker) {
    try {
        const { default: Worker } = await import("web-worker");
        globalThis.Worker = Worker;
        console.log("Node.js: Worker emulation enabled via 'web-worker' module.");
    } catch (e) {
        console.warn("Node.js: 'web-worker' module not found. Workers will not be available in Node.js.");
    }
}

const ENTRIES_COUNT = 16;
const TOTAL_SIZE = 100 * 1024 * 1024; // 100MB
const ENTRY_SIZE = Math.floor(TOTAL_SIZE / ENTRIES_COUNT);

/**
 * Generates compressible random data deterministically.
 */
function getCompressibleData(size) {
    const data = new Uint8Array(size);
    const patternSize = 1024;
    const pattern = new Uint8Array(patternSize);
    // Use a simple deterministic PRNG
    let seed = 42;
    function nextRandom() {
        seed = (seed * 1664525 + 1013904223) % 4294967296;
        return seed / 4294967296;
    }

    for (let i = 0; i < patternSize; i++) {
        pattern[i] = Math.floor(nextRandom() * 256);
    }

    for (let i = 0; i < size; i++) {
        data[i] = pattern[i % patternSize] ^ (i % 7);
    }
    return data;
}

async function writeCSV(results) {
    const header = "Environment,Level,UseCompressionStream,UseWebWorkers,MaxWorkers,ChunkSize,Time(ms),Ratio(%)\n";
    const rows = results.map(r => `${r.env},${r.level},${r.useCompressionStream},${r.useWebWorkers},${r.maxWorkers},${r.chunkSize},${r.duration},${r.ratio}`).join("\n");
    const csv = header + rows + "\n";

    const env = typeof Deno !== "undefined" ? "deno" : (typeof Bun !== "undefined" ? "bun" : "node");
    const filename = `benchmark-results-${env}.csv`;
    if (typeof Deno !== "undefined") {
        await Deno.writeTextFile(filename, csv);
    } else if (typeof Bun !== "undefined") {
        await Bun.write(filename, csv);
    } else {
        const fs = await import("node:fs/promises");
        await fs.writeFile(filename, csv);
    }
    console.log(`\nResults written to ${filename}`);
}

async function runBenchmark(config) {
    const { useWebWorkers, maxWorkers, level, useCompressionStream, chunkSize } = config;

    zip.configure({ useWebWorkers, maxWorkers, useCompressionStream, chunkSize });

    const entriesData = [];
    for (let i = 0; i < ENTRIES_COUNT; i++) {
        entriesData.push({
            name: `entry-${i}.dat`,
            data: getCompressibleData(ENTRY_SIZE)
        });
    }

    const startTime = Date.now();

    const blobWriter = new zip.BlobWriter("application/zip");
    const zipWriter = new zip.ZipWriter(blobWriter);

    // Add entries in parallel
    await Promise.all(entriesData.map((entry) =>
        zipWriter.add(entry.name, new zip.BlobReader(new Blob([entry.data])), {
            level,
            bufferedWrite: true,
            keepOrder: false
        })
    ));

    await zipWriter.close();
    const endTime = Date.now();

    const duration = endTime - startTime;
    const compressedBlob = await blobWriter.getData();

    const compressedSize = compressedBlob.size;
    const ratio = (compressedSize / TOTAL_SIZE * 100).toFixed(2);

    const env = typeof Deno !== "undefined" ? "Deno" : (typeof Bun !== "undefined" ? "Bun" : "Node.js");

    console.log(`[${env}] WW=${useWebWorkers}, CS=${useCompressionStream}, Workers=${maxWorkers}, Level=${level}, Chunk=${chunkSize}`);
    console.log(`Time: ${duration}ms, Ratio: ${ratio}%`);
    console.log('-----------------------------------');

    await zip.terminateWorkers();
    return {
        env,
        level,
        useCompressionStream,
        useWebWorkers,
        maxWorkers,
        chunkSize,
        duration,
        ratio
    };
}

async function main() {
    const levels = [0, 6, 9];
    const useWebWorkersOptions = [true, false];
    const compressionStreamOptions = [true, false];
    const chunkSizes = [64 * 1024, 8 * 1024 * 1024];
    const maxWorkersOptions = [1, 2, 4, 8];

    console.log("=== Zip.js Parallel Compression Benchmark ===");
    console.log(`Total data: ${TOTAL_SIZE / 1024 / 1024}MB across ${ENTRIES_COUNT} entries\n`);

    const results = [];
    for (const level of levels) {
        console.log(`>>> Testing Compression Level: ${level}`);
        for (const useWW of useWebWorkersOptions) {
            for (const useCS of compressionStreamOptions) {
                for (const chunkSize of chunkSizes) {
                    for (const maxWorkers of maxWorkersOptions) {
                        try {
                            const result = await runBenchmark({ 
                                useWebWorkers: useWW, 
                                maxWorkers, 
                                level, 
                                useCompressionStream: useCS, 
                                chunkSize 
                            });
                            results.push(result);
                        } catch (err) {
                            console.error(`Benchmark failed:`, err.message);
                        }
                    }
                }
            }
        }
        console.log("");
    }

    await writeCSV(results);
}

main().catch(console.error);

Results on my M2

Benchmark Conclusion - zip.js Parallel Compression

Performance Test Description

The test evaluates zip.js performance across Node.js, Deno, and Bun. It measures the time and compression ratio for a 128MB deterministic dataset across 288 different configurations:

• Compression Levels: 0 (Store), 6 (Default), and 9 (Max).
• Engines: Native CompressionStream (useCompressionStream: true) vs. WASM Fallback.
• Parallelism: Using Web Workers (useWebWorkers: true) vs. Main Thread only.
• Worker Management: Testing maxWorkers at 1, 2, 4, and 8.
• Chunk Size: Comparing the default 64KB vs. a larger 8MB chunk size.

Notable Facts

• Deno Compression Overhead: Deno's native CompressionStream produces larger files (~1.45% ratio) with the default 64KB chunks compared to Node/Bun (~0.76%). Increasing the chunkSize to 8MB or more eliminates this overhead, bringing Deno's ratio in line with other runtimes.
• Implicit Parallelism: In Node.js and Deno, native CompressionStream scales with maxWorkers even when useWebWorkers is false. This indicates that these runtimes utilize internal thread pools (libuv/Tokio) for stream compression, offloading work from the main JS thread automatically.
• Bun Performance: Bun is the overall winner in raw speed, especially when combined with explicit Web Workers. It consistently achieves the lowest execution times for the same workload.
• WASM Reliability: The WASM engine is consistently slower than native streams but provides bit-identical compression ratios across all three runtimes, making it the preferred choice when total determinism of the compressed output is required.

Conclusion

To maximize the efficiency of zip.js in modern server-side environments:

1. Prefer Native Streams: Use useCompressionStream: true for the best performance.
2. Optimize Chunk Size: Set chunkSize to at least 8MB (or larger, e.g., 128MB for very large files) to avoid ratio bloating in Deno and to reduce syscall overhead in all environments.
3. Use Web Workers selectively: While useWebWorkers: true is always beneficial for WASM, it is primarily necessary for Bun when using native streams. Node and Deno can often achieve similar results without explicit workers due to their internal stream threading.