/** * @hidden * @packageDocumentation Benchmarks for all in-process {@link IOStream} implementations. * * ### Why async is slower than sync * * Every `await` suspension — even of an already-resolved Promise — forces the * JavaScript engine to schedule a **microtask** and resume the caller on the * next checkpoint. In Node.js / V8 this costs roughly **60-70 ns per * `await`** (verified empirically in this environment). For format parsers * that perform thousands of individual stream reads, the overhead accumulates: * * | reads per parse | extra latency | * |----------------:|--------------:| * | 100 | ~7 µs | * | 1 000 | ~70 µs | * | 10 000 | ~700 µs | * | 100 000 | ~7 ms | * * This is **inherent** to the async/await abstraction — it affects all stream * implementations equally because the overhead is in the `await` call itself, * not in the underlying I/O. The sequential-read benchmark below makes this * visible: all implementations converge to the same throughput because 8 192 * microtask suspensions per 1 MiB iteration dominate every other cost. * * The key mitigation: **read the largest possible block at once** in hot code * paths, reducing the total number of `await` calls. * * ### BlobStream cache behaviour * * `BlobStream` uses a **piece table** with per-segment fetch caching: * - First read of a segment issues `blob.slice().arrayBuffer()` and stores * the resulting `Uint8Array` on the segment. * - All subsequent reads of the same range are served from the cache. * - When one `readBlock` spans multiple uncached segments, all * `arrayBuffer()` calls are issued in parallel via `Promise.all`. * * The "warm" benchmarks below share a single pre-loaded stream across all * iterations (lazy-initialised on the first call). The first iteration pays * the cold cost; all subsequent ones are served purely from the cache. * * Run with: * ``` * npx vitest bench * ``` */ export {}; //# sourceMappingURL=iostream.bench.d.ts.map