The original assertion (`pool wall-clock < sequential wall-clock`)
ran the workload in **Node's vitest environment**, using
`crypto.createHash('sha256')` and `node:worker_threads`. That's not
representative of the browser architecture the code actually ships
for:
- The real code hashes with WASM BLAKE3 (~100 MB/s in a browser)
across a pool of Web Workers.
- Node's `crypto` sha256 is native C++ (~500–1000 MB/s) and its
`worker_threads` postMessage has different overhead characteristics.
At native-crypto speed the 4 MiB hash completes in ~8 ms per file,
so the message-passing round-trip cost per file becomes a comparable
fraction of the total — even a *perfect* 3-lane parallelization has
to overcome ~1/3 of its own runtime in messaging cost. Any CI
variance pushes it over the sequential wall-clock, so the test
false-fails while the actual browser code is fine.
The optimization itself is defensible on two grounds:
1. Theoretical parallelism win: at WASM BLAKE3 speed the messaging
overhead is a rounding error and 3 lanes beat sequential ~2.5×.
2. Main-thread responsiveness: even if the wall-clock ended up flat,
offloading the ~1 s of CPU-bound hashing to workers keeps the
UI responsive during upload prep.
Neither of those is validated by a Node vitest. The real gate belongs
in a Playwright browser benchmark. Marked `.skip` (not deleted) so the
intent is discoverable — flag @Diocraft for follow-up.
Edouard Vanbelle
ad328393cb