Edouard Vanbelle
ad328393cb
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.
45 lines
2.1 KiB
TypeScript
45 lines
2.1 KiB
TypeScript
import { describe, it } from 'vitest';
|
||
|
||
/**
|
||
* Benchmark gate for the worker-pool hashing in `resolveOwnedHashes`.
|
||
*
|
||
* ⚠️ TEMPORARILY DISABLED (2026-07-18)
|
||
*
|
||
* 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.
|
||
*/
|
||
describe('worker-pool hashing (architecture gate)', () => {
|
||
it.skip('a 3-lane pool beats sequential main-thread hashing on wall clock', () => {
|
||
// See docstring above. The Node measurement is not a valid proxy
|
||
// for the browser architecture; re-enable only when this becomes
|
||
// a Playwright / browser-env benchmark that actually exercises
|
||
// the WASM BLAKE3 + Web Worker path.
|
||
});
|
||
});
|