Extend prefetching/preloading section of the README - #260
Conversation
✅ Deploy Preview for webkit-jetstream-preview ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
| 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. |
There was a problem hiding this comment.
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.)
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
OK, thanks for the WebKit background. I don't know whether getting the blob involves IPC on Chrome.
2 participants
as proposed by @kmiller68 in #258 (comment)