diff --git a/examples/wasm-viewer/README.md b/examples/wasm-viewer/README.md index 7eb0849..c697357 100644 --- a/examples/wasm-viewer/README.md +++ b/examples/wasm-viewer/README.md @@ -79,6 +79,30 @@ for a deep one) and one batch of requests for its chunks. Every answer is checked — a `206` with exactly the bytes asked for, from the same file (ETag or Last-Modified, and length) — or the call fails. +What that costs, counted on tank on 2026-09-27 (`CHANGELOG.md`, "Remote +files in the browser: fewer round trips"), on an h5py file of 3000 +datasets of 16384 `f32` in one group (198 MB, h5py 3.16 / HDF5 2.0), as +passes / requests / bytes fetched, with +`CLAWHDF5_WASM_LIST_FILE= CLAWHDF5_WASM_READ=/d1500 cargo test +--release -p clawhdf5-wasm --test lazy listing_cost_of_a_given_file -- +--nocapture`: + +| file (`libver`), block size | `list('/')` | open + read one dataset | +|---|---|---| +| earliest, 1 MiB | 4 / 68 / 192.5 MB | 6 / 5 / 5.2 MB | +| earliest, 64 KiB | 5 / 530 / 35.3 MB | 8 / 7 / 0.52 MB | +| latest, 1 MiB | 5 / 86 / 196.5 MB | 7 / 7 / 6.7 MB | +| latest, 64 KiB | 6 / 454 / 30.5 MB | 8 / 8 / 0.58 MB | + +Listing reads every child's object header, and h5py spreads those through +the file, so a listing of a group this large fetches most of it at 1 MiB +blocks; a smaller `blockSize` fetches far less at the cost of more +requests. Reading one dataset does not list the group. In the test suite's +200 MB file (`WASM_BIG_MB=200 bash examples/wasm-viewer/test/run.sh`), +listing the root, reading two small datasets, a group's attributes, the +large dataset's shape and a 10-value window of it took 5 requests and +6 MiB. + `data` is the typed array of the stored width (`Float64Array`, `Float32Array` also for `f16`, `Int8Array` ... `BigInt64Array`, `BigUint64Array`), or an array of strings for fixed- and variable-length @@ -155,25 +179,39 @@ browser). ## Size -Measured 2026-09-26 on tank (rustc 1.98.1, wasm-bindgen 0.2.129, gzip 1.14, -`gzip -9 -n`), after `bash examples/wasm-viewer/build.sh`. The package is -larger now and the table has not been re-measured: the reader has grown -since, and `openUrl` (2026-09-27) made the facade's range-read path -reachable from JavaScript and added promise glue and `remote.js`. +Measured 2026-09-28 on tank at `9b5803f` (rustc 1.98.1, wasm-bindgen +0.2.129, gzip 1.14): `bash examples/wasm-viewer/build.sh`, then `wc -c` and +`gzip -9 -n -c FILE | wc -c` of each file in `pkg/`. The opt-level `z` and +`3` rows are the same build with `CARGO_PROFILE_WASM_RELEASE_OPT_LEVEL=z` +(or `3`) and the same `wasm-bindgen --target web` step. | | raw | gzip -9 | |---|---:|---:| -| `pkg/clawhdf5_wasm_bg.wasm` (profile `wasm-release`, opt-level `s`) | 627,501 B | 191,639 B | -| `pkg/clawhdf5_wasm.js` (wasm-bindgen glue) | 21,826 B | 4,487 B | -| same wasm at opt-level `z` | 693,068 B | 192,550 B | -| same wasm at opt-level `3` | 544,035 B | 198,803 B | +| `pkg/clawhdf5_wasm_bg.wasm` (profile `wasm-release`, opt-level `s`) | 1,384,607 B | 378,485 B | +| `pkg/clawhdf5_wasm.js` (wasm-bindgen glue) | 40,711 B | 8,181 B | +| `pkg/snippets/.../js/remote.js` (the HTTP side of `openUrl`) | 9,326 B | 3,448 B | +| same wasm at opt-level `z` | 1,533,772 B | 374,765 B | +| same wasm at opt-level `3` | 1,184,889 B | 394,569 B | | h5wasm 0.10.3: wasm embedded in `dist/esm/hdf5_util.js` | 3,544,184 B | 907,096 B | | h5wasm 0.10.3: `dist/esm/hdf5_util.js` as shipped | 4,150,134 B | 986,699 B | -h5wasm figures: `npm pack h5wasm@0.10.3` (npm reports -`dist.unpackedSize` 14,731,385 B for the whole package), wasm extracted from -the `binaryDecode` literal in `hdf5_util.js`. h5wasm is the whole of libhdf5 -(writing, every datatype, plugins), so this compares download size, not -equal functionality. No `wasm-opt` pass was applied (binaryen is not -installed on tank). opt-level `s` is used because it is the smallest -compressed. +The previous measurement (2026-09-26, before `openUrl`) was 627,501 B / +191,639 B gzipped for the wasm and 21,826 B / 4,487 B for the glue. The +package roughly doubled since. `openUrl` made the facade's `Storage` read +path reachable from JavaScript (it was compiled out before) and added the +lazy cache and the promise glue (`CHANGELOG.md`, M4); the growth has not +been broken down per change. Of the +wasm's 1,384,607 bytes, 476,062 are the `name` custom section (function +names, which wasm-bindgen keeps; `wasm-bindgen --remove-name-section` or a +`wasm-opt` pass would drop them); code is 816,244 and data 83,431. Without +the name section the wasm is 908,541 B, 329,854 B gzipped (section removed +with a script, not a supported build option yet). At +opt-level `z` the gzipped wasm is now 1% smaller than at `s`, which the +profile still uses. + +h5wasm figures (2026-09-26, unchanged): `npm pack h5wasm@0.10.3` (npm +reports `dist.unpackedSize` 14,731,385 B for the whole package), wasm +extracted from the `binaryDecode` literal in `hdf5_util.js`. h5wasm is the +whole of libhdf5 (writing, every datatype, plugins), so this compares +download size, not equal functionality. No `wasm-opt` pass was applied +(binaryen is not installed on tank).