Skip to content

Extend prefetching/preloading section of the README #260

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
danleh merged 1 commit into from
Jan 15, 2026
Merged

Extend prefetching/preloading section of the README #260

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 13 additions & 7 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -54,15 +54,21 @@ The individual workloads are in subdirectories.

### Preloading and Compression

The JetStream driver (both in the browser and shell runners) _preloads_ some large assets and source files.
That is, it reads those files from disk or fetches them from the network before running the workloads.
This is in order to exclude network latency and disk I/O from the benchmark measurements and reduce variance. Otherwise, OS scheduling or CPU frequency scaling may affect the measurement.

Some workloads also utilize large assets (e.g., ML models, heavy JavaScript bundles in the order of 10s of MBs).
In order to limit the repository size and network transfers, such large assets are stored as compressed .z files.
**Network prefetching (in the browser).**
In order to avoid the CPU frequency spinning down between tests we prefetch all assets before any of the tests start in the browser.
(In the CLI/shell runner we assume all assets are on disk.)
Assets are saved in a blob URL so they can be cached on disk.
This lowers the peak memory footprint of the benchmark to a sustainable level.
Copy link
Contributor Author

@danleh danleh Jan 15, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this true in general (i.e., for non-JSC engines)? I.e., does the content behind a blob URL get swapped out of memory to disk before/between workloads? (My assumption so far was that the benefit of the blob URLs is to avoid another network request during the measurement window and to avoid the OS scheduler and CPU dynamic frequency scaling to affect the measurement due to I/O; not that this has a memory benefit.)

Copy link
Contributor

@kmiller68 kmiller68 Jan 15, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My understanding is that I/O / IPC is fast enough that it doesn't make a noticeable difference in CPU frequency scaling. I'm certainly not an expert in this part of WebKit but our WebInspector indicates the blobs are coming from disk. Additionally, on iOS if all the resources were in memory (in addition to the working set of some of the line items) I think we'd be well past the jetsam limit.

Even if the blobs were kept in memory I think there is still an IPC request in the timing window because we have to get the blob from our networking process. I would assume Chrome/FF have similar behavior?

Copy link
Contributor Author

@danleh danleh Jan 15, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, thanks for the WebKit background. I don't know whether getting the blob involves IPC on Chrome.


**Large asset preloading.**
The JetStream driver (both in the browser and shell runners) preloads some large assets and source files.
This avoids extensive disk I/O during the measurement window of the workloads.

**Compression.**
In order to limit the repository size and network transfers, large assets (e.g., ML models, heavy JavaScript bundles in the order of 10s of MBs) are stored as compressed .z files on disk.
Preloading handles the decompression of these assets (using `DecompressionStream` or a Wasm-based zlib polyfill) upfront so that decompression overhead does not affect the benchmark score.

Both preloading and compression can be disabled, e.g., to inspect raw files or because it sometimes helps with debugging (e.g., proper URLs instead of Blobs for resources).
Preloading, prefetching, and compression can be disabled, e.g., to inspect raw files or because it sometimes helps with debugging (e.g., to get proper URLs instead of blob URLs for resources).

- Compression: Run `npm run decompress` to decompress all .z files before running the benchmark.
- No prefetching for shells: Pass the `--no-prefetch` flag, e.g., `jsc cli.js -- --no-prefetch`.
Expand Down
Loading