@zip.js/zip.js 2.18.2 → 2.20.0

package/BENCHMARKS.md

@@ -1,15 +1,17 @@
 # Benchmarks
 
 Measurements of [@zip.js/zip.js](https://www.npmjs.com/package/@zip.js/zip.js) against
-[jszip](https://github.com/Stuk/jszip), [fflate](https://github.com/101arrowz/fflate) and
-[archiver](https://github.com/archiverjs/node-archiver), of zip.js's own codec backends, and of
+[jszip](https://github.com/Stuk/jszip), [fflate](https://github.com/101arrowz/fflate),
+[archiver](https://github.com/archiverjs/node-archiver) and the
+[ZIP API of `node:zlib`](https://nodejs.org/api/zlib.html#class-zlibzipentry), of zip.js's own
+codec backends, and of
 the runtimes it runs on. Every number on this page comes from the harness in
 [`benchmarks/`](benchmarks/), on the machine, date and versions below. The results are specific
 to them; run the harness on your machine before relying on any of them.
 
 The page answers four questions, each from one or two scripts of the harness:
 
-- [How does zip.js compare with jszip, fflate and archiver?](#zipjs-against-jszip-fflate-and-archiver)
+- [How does zip.js compare with jszip, fflate, archiver and node:zlib?](#zipjs-against-jszip-fflate-archiver-and-nodezlib)
   `bench.js`, on Node.
 - [Which codec backend of zip.js is fastest, and what does concurrent `add()` buy?](#the-codec-backends-of-zipjs)
   `bench-codecs.js` and `bench-backends.js`, on Node.
@@ -22,14 +24,15 @@ The page answers four questions, each from one or two scripts of the harness:
 | | |
 |---|---|
 | Machine | Apple M2, 8 cores (4 performance + 4 efficiency), 16 GB RAM |
-| OS | macOS 26.6.2 (arm64) |
-| Runtimes | Node.js v26.7.0, Bun 1.4.2, Deno 2.9.6 |
-| Browsers | Firefox 154, Chrome 153 (the browser encryption table only) |
-| zip.js | 2.14.0 |
+| OS | macOS 27.0 (arm64) |
+| Runtimes | Node.js v26.10.0, Bun 1.4.2, Deno 2.9.7 |
+| Browsers | Firefox 156, Chrome 153, headless (the browser encryption table only) |
+| zip.js | 2.19.0 |
 | jszip | 3.10.2 |
 | fflate | 0.8.3 |
 | archiver | 8.0.0 |
-| Measured | 2026-09-10; the two encryption tables on 2026-09-12, on the engines that follow 2.14.0 |
+| node:zlib | the ZIP API built into Node.js 26.10.0, experimental, added in 26.8.0 |
+| Measured | 2026-09-30; the browser encryption table on 2026-09-26 |
 
 ## Method
 
@@ -51,29 +54,37 @@ The page answers four questions, each from one or two scripts of the harness:
   table; it is not a verdict.
 - **Memory.** Peak resident set size reported by `/usr/bin/time -l`, as a delta over an empty
   Node process (about 50 MB). It is the highest of the 3 runs, while the time is their median.
-- **Level.** Every library compresses at its own level 6. A level is not a unit shared between
+- **Versions of this page.** A re-run replaces the whole page, and the runtimes, browsers and OS
+  move between two runs along with zip.js, so a number read from an older version of the page
+  is not comparable with one here: only a column measured in the same run isolates a single
+  variable, as the `chunkSize` 64 KB column of the
+  [runtime table](#concurrent-add-per-runtime) does for the default chunk size.
+- **Level.** Every library compresses at its own level 6; the ZIP API of `node:zlib` has no level
+  option and deflates at zlib's default, which is 6. A level is not a unit shared between
   libraries: zlib's level 6 and fflate's level 6 are different parameter sets and produce
   different sizes, so every time is printed next to the size it achieved, and the
   [Codecs](#codecs-at-equal-output-size) table compares by output size instead.
-- **Codecs.** Every head-to-head table names the codec of each row. archiver runs Node's `zlib`
-  module, the host's zlib written in C; jszip (pako) and fflate deflate and inflate in
-  JavaScript. zip.js selects its codec at runtime, so it has one row per backend: the
+- **Codecs.** Every head-to-head table names the codec of each row. archiver and the ZIP API of
+  `node:zlib` run Node's `zlib` module, the host's zlib written in C; jszip (pako) and fflate
+  deflate and inflate in JavaScript. zip.js selects its codec at runtime, so it has one row per backend: the
   `CompressionStream` and `DecompressionStream` of the runtime, Node's zlib here and the default
   where they exist; the bundled WebAssembly zlib; and the pure-JavaScript zlib port. The last two
   ship with the library, like the codecs of jszip and fflate, so those rows compare the
   libraries without the host's zlib in the picture.
 - **Checks.** No decompression row verifies the CRC-32 of the entries: zip.js and jszip leave
-  the check off by default, and fflate has none on read. Turning it on in zip.js makes the
+  the check off by default, fflate has none on read, and `node:zlib` verifies by default so its
+  row passes `verify: false`. Turning it on in zip.js makes the
   inflater verify the CRC-32 through a gzip trailer: about 7 ms per 20 MB on the WebAssembly
   codec, within the noise on Node's `DecompressionStream`; the pure-JavaScript port keeps a
   separate pass over the output, about 15 ms.
 - **Units.** MB in the tables is 10^6 bytes. The workload sizes (20 MB, 8 MB, 256 MB) and the
   MB/s throughputs use 2^20 bytes.
 
-## zip.js against jszip, fflate and archiver
+## zip.js against jszip, fflate, archiver and node:zlib
 
 One Node process per measurement (`benchmarks/bench.js`), one thread, every library at its
-level 6. zip.js appears once per codec backend.
+level 6. zip.js appears once per codec backend. The `node:zlib` rows use the ZIP API built into
+Node.js since 26.8.0: `ZipEntry.create()` and `createZipArchive()` to write, `ZipBuffer` to read.
 
 ### Compression
 
@@ -82,33 +93,37 @@ size each row produced:
 
 | Library | Codec | Compressible text (20 MB) | Incompressible data (20 MB) | 5,000 files × ~2 KB |
 |---|---|--:|--:|--:|
-| @zip.js/zip.js | `CompressionStream` | **700 ms** / 6.1 MB | 365 ms / 21.0 MB | 888 ms / 4.9 MB |
-| @zip.js/zip.js | WASM zlib | 1057 ms / 6.2 MB | 475 ms / 21.0 MB | 679 ms / 4.9 MB |
-| @zip.js/zip.js | pure-JS zlib | 1238 ms / 6.2 MB | 802 ms / 21.0 MB | 1125 ms / 4.9 MB |
-| jszip | pako (JavaScript) | 1723 ms / 6.2 MB | 862 ms / 21.0 MB | 843 ms / 4.7 MB |
-| fflate | fflate (JavaScript) | 909 ms / 6.3 MB | **297 ms** / 21.0 MB | **281 ms** / 4.8 MB |
-| archiver | Node `zlib` (C) | 702 ms / 6.1 MB | 359 ms / 21.0 MB | 424 ms / 4.8 MB |
+| @zip.js/zip.js | `CompressionStream` | 730 ms / 6.1 MB | 357 ms / 21.0 MB | 731 ms / 4.9 MB |
+| @zip.js/zip.js | WASM zlib | 1098 ms / 6.2 MB | 460 ms / 21.0 MB | 551 ms / 4.9 MB |
+| @zip.js/zip.js | pure-JS zlib | 1229 ms / 6.2 MB | 787 ms / 21.0 MB | 962 ms / 4.9 MB |
+| jszip | pako (JavaScript) | 1753 ms / 6.2 MB | 854 ms / 21.0 MB | 846 ms / 4.7 MB |
+| fflate | fflate (JavaScript) | 908 ms / 6.3 MB | **298 ms** / 21.0 MB | **278 ms** / 4.8 MB |
+| archiver | Node `zlib` (C) | 708 ms / 6.1 MB | 359 ms / 21.0 MB | 423 ms / 4.8 MB |
+| node:zlib | Node `zlib` (C) | **678 ms** / 6.1 MB | 346 ms / 21.0 MB | 371 ms / 4.7 MB |
 
 Peak memory for the same runs (Δ over baseline):
 
 | Library | Codec | Compressible text (20 MB) | Incompressible data (20 MB) | 5,000 files × ~2 KB |
 |---|---|--:|--:|--:|
-| @zip.js/zip.js | `CompressionStream` | 91 MB | 153 MB | 245 MB |
-| @zip.js/zip.js | WASM zlib | 119 MB | 170 MB | 250 MB |
-| @zip.js/zip.js | pure-JS zlib | 114 MB | 172 MB | 276 MB |
-| jszip | pako (JavaScript) | 69 MB | 93 MB | 269 MB |
-| fflate | fflate (JavaScript) | **62 MB** | 108 MB | **102 MB** |
-| archiver | Node `zlib` (C) | 72 MB | **74 MB** | 137 MB |
-
-On the text file zip.js with `CompressionStream` and archiver take the same time, 700 and
-702 ms, for the same output size: both run Node's zlib. With the codecs that ship with each
-library, fflate takes 909 ms for 2 % more bytes, zip.js's WebAssembly zlib 1057 ms, its
-pure-JavaScript port 1238 ms and jszip 1723 ms. On incompressible data fflate is the fastest row
-and archiver the smallest in memory. On 5,000 small files the WebAssembly backend is 23 % faster
-than `CompressionStream`, so a native stream costs more per entry than a WebAssembly one; fflate
-takes 41 % of the WebAssembly row's time there against 86 % on the 20 MB file, and the
-difference is the work zip.js does per entry, a stream and a header each. The zip.js rows use
-the most memory on the two 20 MB files.
+| @zip.js/zip.js | `CompressionStream` | 115 MB | 184 MB | 262 MB |
+| @zip.js/zip.js | WASM zlib | 139 MB | 206 MB | 244 MB |
+| @zip.js/zip.js | pure-JS zlib | 126 MB | 182 MB | 287 MB |
+| jszip | pako (JavaScript) | 76 MB | 102 MB | 269 MB |
+| fflate | fflate (JavaScript) | 68 MB | 114 MB | **106 MB** |
+| archiver | Node `zlib` (C) | 78 MB | 90 MB | 151 MB |
+| node:zlib | Node `zlib` (C) | **51 MB** | **82 MB** | 245 MB |
+
+On the text file the three rows that run Node's zlib take the same time within 8 %, for the
+same output size: `node:zlib` 678 ms, archiver 708 ms and zip.js with `CompressionStream`
+730 ms. With the codecs that ship with each library, fflate takes 908 ms for 2 % more bytes,
+zip.js's WebAssembly zlib 1098 ms, its pure-JavaScript port 1229 ms and jszip 1753 ms. On
+incompressible data fflate is the fastest row and `node:zlib` the smallest in memory. On 5,000
+small files the WebAssembly backend is 25 % faster than `CompressionStream`, so a native stream
+costs more per entry than a WebAssembly one; fflate takes 50 % of the WebAssembly row's time
+there against 83 % on the 20 MB file, and the difference is the work zip.js does per entry, a
+stream and a header each. `node:zlib` takes 371 ms on the same files and archiver 423 ms, both
+on the same zlib as `CompressionStream`. The zip.js rows use the most memory on the two 20 MB
+files, where `node:zlib`, which holds one buffer per entry and no stream, uses the least.
 
 ### Decompression
 
@@ -117,56 +132,59 @@ excluded.
 
 | Library | Codec | Compressible text (20 MB) | 5,000 files × ~2 KB |
 |---|---|--:|--:|
-| @zip.js/zip.js | `DecompressionStream` | **66 ms** | 628 ms |
-| @zip.js/zip.js | WASM zlib | 78 ms | 476 ms |
-| @zip.js/zip.js | pure-JS zlib | 180 ms | 615 ms |
-| jszip | pako (JavaScript) | 137 ms | 444 ms |
-| fflate | fflate (JavaScript) | 116 ms | **102 ms** |
+| @zip.js/zip.js | `DecompressionStream` | 64 ms | 485 ms |
+| @zip.js/zip.js | WASM zlib | 71 ms | 342 ms |
+| @zip.js/zip.js | pure-JS zlib | 155 ms | 527 ms |
+| jszip | pako (JavaScript) | 140 ms | 438 ms |
+| fflate | fflate (JavaScript) | 116 ms | **101 ms** |
+| node:zlib | Node `zlib` (C) | **60 ms** | 183 ms |
 
 Peak memory for the same runs (Δ over baseline):
 
 | Library | Codec | Compressible text (20 MB) | 5,000 files × ~2 KB |
 |---|---|--:|--:|
-| @zip.js/zip.js | `DecompressionStream` | 116 MB | 350 MB |
-| @zip.js/zip.js | WASM zlib | 163 MB | 484 MB |
-| @zip.js/zip.js | pure-JS zlib | 154 MB | 451 MB |
-| jszip | pako (JavaScript) | 103 MB | 306 MB |
-| fflate | fflate (JavaScript) | **92 MB** | **120 MB** |
-
-On the 20 MB stream `DecompressionStream` takes 66 ms and the WebAssembly inflate 78 ms, then
-fflate 116 ms, jszip 137 ms and the pure-JavaScript port 180 ms. The WebAssembly row includes
-the module instantiation a fresh process pays once, about 20 ms. Warm, the two inflates are
-within 6 % of each other in the [Codecs](#codecs-at-equal-output-size) table. On 5,000 small
-files the order reverses: fflate takes 102 ms, jszip 444 ms and the three zip.js rows 476 to
-628 ms, with `DecompressionStream` the slowest of them, the same per-entry cost as in
-compression. fflate uses the least memory on both workloads, 34 % of the `DecompressionStream`
-row on the small files, and the WebAssembly and pure-JavaScript rows peak higher than
-`DecompressionStream`. The three zip.js rows allocate the same 800 MB of stream objects over the
-5,000 entries, about 160 KB per entry. The WebAssembly and pure-JavaScript codecs run on the
-JavaScript thread, so V8's incremental marking keeps more of that garbage alive between
-collections, and that is the difference between the rows.
+| @zip.js/zip.js | `DecompressionStream` | 151 MB | 355 MB |
+| @zip.js/zip.js | WASM zlib | 171 MB | 358 MB |
+| @zip.js/zip.js | pure-JS zlib | 158 MB | 353 MB |
+| jszip | pako (JavaScript) | 103 MB | 284 MB |
+| fflate | fflate (JavaScript) | **97 MB** | **123 MB** |
+| node:zlib | Node `zlib` (C) | 99 MB | 255 MB |
+
+On the 20 MB stream `node:zlib` takes 60 ms and `DecompressionStream` 64 ms, the same zlib
+reached two ways, then the WebAssembly inflate 71 ms, fflate 116 ms, jszip 140 ms and the
+pure-JavaScript port 155 ms. The WebAssembly row includes the module instantiation a fresh
+process pays once, about 20 ms. Warm, the WebAssembly inflate is 27 % faster than
+`DecompressionStream` in the [Codecs](#codecs-at-equal-output-size) table. On 5,000 small files
+the order changes: fflate takes 101 ms, `node:zlib` 183 ms, then the WebAssembly row 342 ms,
+jszip 438 ms, `DecompressionStream` 485 ms and the pure-JavaScript port 527 ms, the same
+per-entry cost as in compression. fflate uses the least memory on both workloads, 35 % of the
+`DecompressionStream` row on the small files. The three zip.js rows allocate the same 800 MB of
+stream objects over the 5,000 entries, about 160 KB per entry, and peak within 5 MB of each
+other.
 
 ### Streaming a 256 MB file, disk to disk
 
 One file read with `fs.createReadStream` in 64 KB chunks and one archive written with
 `fs.createWriteStream`, one entry, each library's streaming API. zip.js takes Web Streams, so its
 rows go through Node's `Readable.toWeb` and `Writable.toWeb` bridges; the other libraries take
-the Node streams directly.
+the Node streams directly, `node:zlib` through `ZipEntry.createStream()`.
 
 | Library | Codec | Median time | Peak memory (Δ) | Output |
 |---|---|--:|--:|--:|
-| @zip.js/zip.js | `CompressionStream` | **9055 ms** | 62 MB | 78.3 MB |
-| archiver | Node `zlib` (C) | 9115 ms | 71 MB | 78.3 MB |
-| fflate | fflate (JavaScript) | 12456 ms | **41 MB** | 80.2 MB |
-| @zip.js/zip.js | WASM zlib | 13629 ms | 88 MB | 78.9 MB |
-| @zip.js/zip.js | pure-JS zlib | 15485 ms | 120 MB | 78.9 MB |
-| jszip | pako (JavaScript) | 22539 ms | 74 MB | 78.9 MB |
-
-Every row streams: the peaks stay between 41 MB (fflate) and 120 MB (the pure-JavaScript port)
-over baseline on the 256 MB input. zip.js with `CompressionStream` and archiver take the same
-time within 1 %; jszip takes 2.5× that. With its WebAssembly zlib zip.js takes 1.5× the
-`CompressionStream` time and 1.1× fflate's, for 1.6 % fewer bytes; the pure-JavaScript port
-takes 1.2× fflate's time.
+| node:zlib | Node `zlib` (C) | **8905 ms** | **42 MB** | 78.3 MB |
+| @zip.js/zip.js | `CompressionStream` | 8926 ms | 117 MB | 78.3 MB |
+| archiver | Node `zlib` (C) | 9167 ms | 81 MB | 78.3 MB |
+| fflate | fflate (JavaScript) | 12781 ms | 57 MB | 80.2 MB |
+| @zip.js/zip.js | WASM zlib | 13405 ms | 128 MB | 78.9 MB |
+| @zip.js/zip.js | pure-JS zlib | 15326 ms | 123 MB | 78.9 MB |
+| jszip | pako (JavaScript) | 22809 ms | 83 MB | 78.9 MB |
+
+Every row streams: the peaks stay between 42 MB (`node:zlib`) and 128 MB (the WebAssembly zlib)
+over baseline on the 256 MB input. The three rows on Node's zlib take the same time within 3 %;
+jszip takes 2.6× that. With its WebAssembly zlib zip.js takes 1.5× the `CompressionStream` time
+and 1.05× fflate's, for 1.6 % fewer bytes; the pure-JavaScript port takes 1.2× fflate's time.
+The 256 KB chunks zip.js holds at each stage of its pipeline are what separates its
+`CompressionStream` row from `node:zlib` in memory, 117 against 42 MB, at the same speed.
 
 ## The codec backends of zip.js
 
@@ -187,20 +205,20 @@ fastest such row. A row with an empty last column is beaten by nothing on the ta
 
 | Codec | Setting | Output | Ratio | Time | Throughput | Beaten by |
 |---|---|--:|--:|--:|--:|---|
-| WASM zlib | level 8 | 6,115,980 | 3.429 | 1504 ms | 13.3 MB/s | |
-| `CompressionStream` | no level control | 6,120,503 | 3.426 | 716 ms | 27.9 MB/s | |
-| WASM zlib | level 6 | 6,165,103 | 3.402 | 1047 ms | 19.1 MB/s | `CompressionStream` |
-| fflate | level 8, its best | 6,239,025 | 3.361 | 767 ms | 26.1 MB/s | `CompressionStream` |
-| fflate | level 6 | 6,257,881 | 3.351 | 815 ms | 24.6 MB/s | `CompressionStream` |
-| WASM zlib | level 5 | 6,562,182 | 3.196 | 505 ms | 39.6 MB/s | |
-| fflate | level 5 | 6,648,574 | 3.154 | 541 ms | 36.9 MB/s | WASM zlib level 5 |
-| WASM zlib | level 4 | 6,907,987 | 3.036 | 278 ms | 71.9 MB/s | |
-| fflate | level 1 | 7,261,700 | 2.888 | 318 ms | 62.9 MB/s | WASM zlib level 4 |
-| WASM zlib | level 2 | 7,359,387 | 2.850 | 195 ms | 102.5 MB/s | |
-| WASM zlib | level 1 | 7,531,042 | 2.785 | 175 ms | 114.1 MB/s | |
+| WASM zlib | level 8 | 6,115,980 | 3.429 | 1486 ms | 13.5 MB/s | |
+| `CompressionStream` | no level control | 6,120,503 | 3.426 | 695 ms | 28.8 MB/s | |
+| WASM zlib | level 6 | 6,165,103 | 3.402 | 1025 ms | 19.5 MB/s | `CompressionStream` |
+| fflate | level 8, its best | 6,239,025 | 3.361 | 755 ms | 26.5 MB/s | `CompressionStream` |
+| fflate | level 6 | 6,257,881 | 3.351 | 751 ms | 26.6 MB/s | `CompressionStream` |
+| WASM zlib | level 5 | 6,562,182 | 3.196 | 493 ms | 40.6 MB/s | |
+| fflate | level 5 | 6,648,574 | 3.154 | 534 ms | 37.5 MB/s | WASM zlib level 5 |
+| WASM zlib | level 4 | 6,907,987 | 3.036 | 277 ms | 72.3 MB/s | |
+| fflate | level 1 | 7,261,700 | 2.888 | 319 ms | 62.8 MB/s | WASM zlib level 4 |
+| WASM zlib | level 2 | 7,359,387 | 2.850 | 210 ms | 95.0 MB/s | |
+| WASM zlib | level 1 | 7,531,042 | 2.785 | 173 ms | 115.8 MB/s | |
 
 The pure-JavaScript port produces the same size as the WebAssembly codec at every level and
-takes 1.0 to 1.8× its time, the gap closing at the higher levels; the full 28-row table is in
+takes 1.0 to 1.9× its time, the gap closing at the higher levels; the full 28-row table is in
 `benchmarks/results/codecs-results.json`.
 
 Every fflate row is beaten by a zlib row: by the host's `CompressionStream` at fflate's levels 6
@@ -212,16 +230,16 @@ Decompression of the same stream:
 
 | Codec | Time | Throughput |
 |---|--:|--:|
-| WASM zlib | **54 ms** | 369.5 MB/s |
-| `DecompressionStream` | 57 ms | 352.6 MB/s |
-| pure-JS zlib | 111 ms | 180.6 MB/s |
-| fflate | 128 ms | 156.0 MB/s |
+| WASM zlib | **41 ms** | 483.7 MB/s |
+| `DecompressionStream` | 56 ms | 359.1 MB/s |
+| pure-JS zlib | 108 ms | 185.1 MB/s |
+| fflate | 122 ms | 164.4 MB/s |
 
-The WebAssembly inflate and Node's `DecompressionStream` are within 6 % of each other; fflate's
-inflate takes 2.4× the time of the WebAssembly one, the pure-JavaScript port 2.1×.
+The WebAssembly inflate is 27 % faster than Node's `DecompressionStream`; fflate's inflate takes
+3.0× the time of the WebAssembly one, the pure-JavaScript port 2.6×.
 
-Alone, the WebAssembly backend deflates at level 6 in 1.46× the time of `CompressionStream` for
-0.7 % more bytes and inflates within 6 % of `DecompressionStream`. zip.js uses it by itself
+Alone, the WebAssembly backend deflates at level 6 in 1.47× the time of `CompressionStream` for
+0.7 % more bytes and inflates 27 % faster than `DecompressionStream`. zip.js uses it by itself
 when no `CompressionStream` exists or when a level other than the default is requested;
 `useCompressionStream: false` selects it on every host, for an output that does not depend on
 the host's zlib.
@@ -234,22 +252,28 @@ that buys with each backend.
 
 | Configuration | Median time | Output | vs jszip |
 |---|--:|--:|--:|
-| **zip.js — `CompressionStream`, concurrent `add()`** | **676 ms** | 19.6 MB | **8.6×** |
-| fflate — async (its own worker pool) | 768 ms | 20.0 MB | 7.5× |
-| archiver — Node zlib | 2324 ms | 19.6 MB | 2.5× |
-| zip.js — `CompressionStream`, sequential `add()` | 2421 ms | 19.6 MB | 2.4× |
-| fflate — `zipSync` (single thread) | 3165 ms | 20.0 MB | 1.8× |
-| zip.js — WASM zlib, sequential `add()` | 3553 ms | 19.7 MB | 1.6× |
-| zip.js — WASM zlib, concurrent `add()` | 3577 ms | 19.7 MB | 1.6× |
-| zip.js — pure-JS zlib, concurrent `add()` | 3954 ms | 19.7 MB | 1.5× |
-| zip.js — pure-JS zlib, sequential `add()` | 4008 ms | 19.7 MB | 1.4× |
-| jszip (pako, single thread) | 5788 ms | 19.7 MB | 1.0× |
-
-With the host's `CompressionStream`, zip.js goes from 2421 ms with sequential `add()` calls to
-676 ms with concurrent ones, 3.6×, without Web Workers: Node runs `CompressionStream` off the
+| node:zlib — `ZipEntry.create()` for every entry at once | **596 ms** | 19.6 MB | **9.6×** |
+| **zip.js — `CompressionStream`, concurrent `add()`** | **602 ms** | 19.6 MB | **9.5×** |
+| fflate — async (its own worker pool) | 757 ms | 20.0 MB | 7.6× |
+| node:zlib — `ZipEntry.create()` one entry at a time | 2209 ms | 19.6 MB | 2.6× |
+| zip.js — `CompressionStream`, sequential `add()` | 2257 ms | 19.6 MB | 2.5× |
+| archiver — Node zlib | 2278 ms | 19.6 MB | 2.5× |
+| fflate — `zipSync` (single thread) | 3191 ms | 20.0 MB | 1.8× |
+| zip.js — WASM zlib, sequential `add()` | 3367 ms | 19.7 MB | 1.7× |
+| zip.js — WASM zlib, concurrent `add()` | 3402 ms | 19.7 MB | 1.7× |
+| zip.js — pure-JS zlib, sequential `add()` | 3868 ms | 19.7 MB | 1.5× |
+| zip.js — pure-JS zlib, concurrent `add()` | 3930 ms | 19.7 MB | 1.5× |
+| jszip (pako, single thread) | 5719 ms | 19.7 MB | 1.0× |
+
+With the host's `CompressionStream`, zip.js goes from 2257 ms with sequential `add()` calls to
+602 ms with concurrent ones, 3.7×, without Web Workers: Node runs `CompressionStream` off the
 main thread, so the entries compress on several cores while the JavaScript thread only feeds
-them. fflate's async API, which runs its own worker pool, takes 768 ms on the same input; its
-output is 2 % larger than the zlib rows, so it does slightly less work. The WebAssembly and
+them. The ZIP API of `node:zlib` gets the same 3.7× from the same threadpool when its
+`ZipEntry.create()` calls are issued at once, 2209 to 596 ms, the same time as zip.js within
+noise; the difference is in memory, not time: `node:zlib` holds every compressed entry until
+`createZipArchive()` serializes them, while zip.js writes each entry as its codec finishes.
+fflate's async API, which runs its own worker pool, takes 757 ms on the same input; its output
+is 2 % larger than the zlib rows, so it does slightly less work. The WebAssembly and
 pure-JavaScript backends run on the main thread, and concurrent `add()` changes nothing for them.
 
 Requesting a non-default level, e.g. `{ level: 5 }`, selects the bundled codec instead of
@@ -269,22 +293,23 @@ JavaScript thread. Same 8 × 8 MB workload as the backends table, level 6. That
 process per run and this one measures in-process after a warmup, which is why their Node numbers
 differ:
 
-| Runtime | sequential `add()` | concurrent `add()` | concurrent `add()`, `chunkSize` 256 KB | concurrent `add()` + `useWebWorkers` |
+| Runtime | sequential `add()` | concurrent `add()` | concurrent `add()`, `chunkSize` 64 KB | concurrent `add()` + `useWebWorkers` |
 |---|--:|--:|--:|--:|
-| Node.js v26.7.0 | 2.25 s | **0.59 s** | 0.59 s | 0.59 s |
-| Bun 1.4.2 | 1.19 s | 1.19 s | **0.24 s** | 0.25 s |
-| Deno 2.9.6 | 1.31 s | 1.31 s | 1.33 s | **0.34 s** |
+| Node.js v26.10.0 | 2.25 s | **0.62 s** | 0.59 s | 0.59 s |
+| Bun 1.4.2 | 1.19 s | **0.26 s** | 1.20 s | 0.27 s |
+| Deno 2.9.7 | 1.35 s | 1.35 s | 1.39 s | **0.37 s** |
 
 - **Node** runs `CompressionStream` off the JavaScript thread, on the libuv threadpool, four
-  threads by default (`UV_THREADPOOL_SIZE`): concurrent `add()` alone is 3.8× faster than
+  threads by default (`UV_THREADPOOL_SIZE`): concurrent `add()` alone is 3.6× faster than
   sequential, and the chunk size changes nothing. Node has no `Worker` global, so
   `useWebWorkers` spawns nothing there and the entries run in-process, in the same time.
 - **Bun** runs `CompressionStream` off the JavaScript thread only for writes larger than 128 KB
-  (its native implementation, since Bun 1.4 in August 2026). zip.js writes 64 KB chunks by
-  default, so concurrent `add()` alone gains nothing on Bun; `chunkSize: 256 * 1024` makes it
-  4.9× faster, and `useWebWorkers: true` 4.7×.
+  (its native implementation, since Bun 1.4 in August 2026). With the 256 KB chunks zip.js
+  writes by default, concurrent `add()` alone is 4.5× faster than sequential; with the 64 KB
+  chunks that were the default up to version 2.18.2 it gains nothing, and `useWebWorkers: true`
+  is 4.5× faster too.
 - **Deno** runs `CompressionStream` on the JavaScript thread whatever the write size: concurrent
-  `add()` alone gains nothing, `useWebWorkers: true` is 3.9× faster.
+  `add()` alone gains nothing, `useWebWorkers: true` is 3.6× faster.
 
 ### Compression levels
 
@@ -294,13 +319,13 @@ column runs the same JavaScript on each engine. One 20 MB text entry, one thread
 
 | Runtime | level 6, `CompressionStream` | level 5, WASM zlib | level 5, pure-JS zlib | level 1, WASM zlib |
 |---|--:|--:|--:|--:|
-| Node.js v26.7.0 | 686 ms / 6.12 MB | 521 ms / 6.56 MB | 780 ms / 6.56 MB | 192 ms / 7.53 MB |
-| Bun 1.4.2 | 371 ms / 6.20 MB | 464 ms / 6.56 MB | 665 ms / 6.56 MB | 168 ms / 7.53 MB |
-| Deno 2.9.6 | 403 ms / 6.21 MB | 590 ms / 6.56 MB | 689 ms / 6.56 MB | 228 ms / 7.53 MB |
+| Node.js v26.10.0 | 691 ms / 6.12 MB | 512 ms / 6.56 MB | 774 ms / 6.56 MB | 186 ms / 7.53 MB |
+| Bun 1.4.2 | 430 ms / 6.20 MB | 465 ms / 6.56 MB | 665 ms / 6.56 MB | 166 ms / 7.53 MB |
+| Deno 2.9.7 | 409 ms / 6.20 MB | 592 ms / 6.56 MB | 682 ms / 6.56 MB | 236 ms / 7.53 MB |
 
-On Node, level 5 on the WebAssembly codec is 24 % faster than the default for 7 % more bytes.
+On Node, level 5 on the WebAssembly codec is 26 % faster than the default for 7 % more bytes.
 On Bun and Deno the default is already faster than level 5, so level 5 there is slower and
-larger; only level 1 buys speed on them, 55 % on Bun and 44 % on Deno, at 21 % more bytes. The
+larger; only level 1 buys speed on them, 61 % on Bun and 42 % on Deno, at 21 % more bytes. The
 pure-JavaScript port at level 5 takes 1.5× the WebAssembly time on Node, 1.4× on Bun and 1.2×
 on Deno, and is slower than the default on every runtime. The two bundled codecs produce the
 same size on every runtime; the level-6 sizes differ because they come from three different
@@ -310,17 +335,17 @@ zlib builds.
 
 On bulk data zip.js adds almost nothing over the host's `CompressionStream`, so its throughput is
 that of the zlib the runtime ships, and they differ. One 256 MB text file, one thread, in
-memory, fed in 64 KB writes as zip.js does; gzip is Apple's, timed as a child process:
+memory, fed in 256 KB writes as zip.js does; gzip is Apple's, timed as a child process:
 
 | Runtime | `CompressionStream` alone | zip.js, one entry | Output |
 |---|--:|--:|--:|
-| Node.js v26.7.0 | 8.99 s | 8.78 s | 78.3 MB |
-| Bun 1.4.2 | 4.73 s | 4.77 s | 79.4 MB |
-| Deno 2.9.6 | 5.13 s | 5.23 s | 79.5 MB |
-| Apple `gzip -6`, classic zlib | 12.3 to 12.4 s | | 78.9 MB |
+| Node.js v26.10.0 | 9.06 s | 9.10 s | 78.3 MB |
+| Bun 1.4.2 | 4.74 s | 4.85 s | 79.4 MB |
+| Deno 2.9.7 | 5.22 s | 5.21 s | 79.4 MB |
+| Apple `gzip -6`, classic zlib | 12.4 to 12.5 s | | 78.9 MB |
 
-zip.js is within 2 % of the raw stream on every runtime. On this file Bun's `CompressionStream`
-takes 53 % of Node's time and Deno's 57 %, for about 1.5 % more bytes; Apple's gzip takes 1.4×
+zip.js is within 3 % of the raw stream on every runtime. On this file Bun's `CompressionStream`
+takes 52 % of Node's time and Deno's 58 %, for about 1.4 % more bytes; Apple's gzip takes 1.4×
 Node's time. Which zlib each runtime ships is not verified here; the table measures the result.
 
 ## Encryption: AES-256 on a stored entry
@@ -334,29 +359,29 @@ one archive written, then read back.
 
 | Engine | Node.js | Bun | Deno |
 |---|--:|--:|--:|
-| WebAssembly, linked into the module of the WebAssembly builds | **131 / 130 MB/s** | **118 / 121** | 123 / 122 |
-| JavaScript, the fallback of those builds and the engine of the native and core builds | 114 / 114 | 112 / 111 | **142 / 129** |
-| 2.13.1, sjcl | 25 / 25 | 27 / 27 | 19 / 19 |
+| WebAssembly, linked into the module of the WebAssembly builds | **134 / 135 MB/s** | **119 / 121** | 124 / 124 |
+| JavaScript, the fallback of those builds and the engine of the native and core builds | 119 / 108 | 115 / 117 | **144 / 133** |
+| 2.13.1, sjcl (measured on 2026-09-26, Node.js v26.7.0) | 26 / 26 | 28 / 28 | 20 / 19 |
 
 The same measurement in a browser, through the Web Worker pool, on 32 MB of bytes generated in
 the page (the corpus is not served to the browser), median of 3 passes
 ([`benchmarks/bench-aes.html`](benchmarks/bench-aes.html), which prints its result and writes no
 file):
 
-| Engine | Firefox 154 | Chrome 153 |
+| Engine | Firefox 156 | Chrome 153 |
 |---|--:|--:|
-| WebAssembly | **96 / 101 MB/s** | **118 / 121** |
-| JavaScript | 68 / 69 | 100 / 98 |
+| WebAssembly | **125 / 125 MB/s** | **136 / 138** |
+| JavaScript | 79 / 79 | 104 / 104 |
 | 2.13.1, sjcl | 17 / 17 | 22 / 22 |
 
-- The JavaScript engine is 4.0 to 4.6× sjcl on Node, Bun and in the two browsers, and 6.8 to
-  7.5× on Deno, where sjcl was slowest. sjcl ran the cipher 16 bytes
+- The JavaScript engine is 4.1 to 4.7× sjcl on Node, Bun and in the two browsers, and 7.0 to
+  7.2× on Deno, where sjcl was slowest. sjcl ran the cipher 16 bytes
   at a time through a bit-array layer; the new engine works on typed arrays and is fed whole
   chunks, with the AES rounds and the SHA-1 steps written out. Every build has it.
 - The WebAssembly kernel is the same C code on every host, with the same rounds written out:
-  118 to 131 MB/s on Node, Bun and Deno, 96 to 121 MB/s in the two browsers. The JavaScript
-  engine is within 13 % of it on Node and Bun, ahead of it on Deno, and 1.2 to 1.4× slower in
-  the browsers. The WebAssembly builds use
+  119 to 135 MB/s on Node, Bun and Deno, 125 to 138 MB/s in the two browsers. The JavaScript
+  engine is within 4 % of it on Bun and 20 % on Node, ahead of it on Deno, and 1.3 to 1.6×
+  slower in the browsers. The WebAssembly builds use
   the kernel whenever their module loads and fall back to the JavaScript engine when it cannot,
   for instance under a Content Security Policy that does not allow WebAssembly
   (`'wasm-unsafe-eval'`).
@@ -369,8 +394,8 @@ file):
   bytes in 2.13.1 to 67,820 in 2.14.0, `dist/zip-native.min.js` from 73,798 to 72,060 and
   `dist/zip-core.min.js` from 36,405 to 35,493 (`git show <tag>:<file> | gzip -9 | wc -c`):
   sjcl's removal outweighs the JavaScript engine and the kernel. Writing the rounds out after
-  2.14.0 gives some of it back: 71,238, 73,339 and 36,235 bytes for the three files behind the
-  encryption tables above.
+  2.14.0 gave some of it back, and the three files behind the encryption tables above gzip to
+  73,184, 75,050 and 37,264 bytes.
 
 ## Reproduce
 
@@ -379,7 +404,7 @@ The harness lives in [`benchmarks/`](benchmarks/). `bench.js` and `bench-backend
 
 ```sh
 cd benchmarks
-npm install              # jszip, fflate, archiver (zip.js is used from the repository)
+npm install              # jszip, fflate, archiver (zip.js is used from the repository, node:zlib is built in)
 npm run corpus           # generate the datasets under .corpus/
 node bench.js            # the head-to-head tables: compress, decompress, disk streaming
 node bench-backends.js   # the concurrent add() and backends table
@@ -390,7 +415,10 @@ node bench-runtimes.js   # the runtime tables; also: bun bench-runtimes.js, deno
 
 Each script writes its JSON to `benchmarks/results/`; the `*-run.log` files there are the
 console output of the runs behind this page. `RUNS=<n>` sets the number of repetitions (default
-3, 5 in `bench-aes.js`). `ZIPJS_BUNDLE=<path to a previous index.min.js> node bench-aes.js` adds
+3, 5 in `bench-aes.js`). `QUICK=1` divides every workload by 8, runs each measurement once and
+writes under `benchmarks/results/quick/`; the scripts then finish in seconds instead of minutes,
+which is enough to check that they run and not enough to read a number from.
+`ZIPJS_BUNDLE=<path to a previous index.min.js> node bench-aes.js` adds
 the row of a previous release; `git show v2.13.1:index.min.js` gave the sjcl row. The browser
 encryption table comes from `benchmarks/bench-aes.html`, served from the repository root
 (`npx http-server -p 8080`, then `http://localhost:8080/benchmarks/bench-aes.html`), with

package/deno.json

@@ -1,6 +1,6 @@
 {
 	"name": "@zip-js/zip-js",
-	"version": "2.18.2",
+	"version": "2.20.0",
 	"exports": {
 		".": "./index.js",
 		"./external": "./lib/zip-fs-external.js",