You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Wasm runner(s) (both the new WasmEMCCBenchmark and the WasmLegacyBenchmark) do an unnecessary second request/fetch for resources in plan.preload. See attached screenshot, for example with gcc-loops-wasm:
In most cases, browsers will fulfill the second request from the cache (as it is here), but we should still clean this up. A naive or misconfigured web server could potentially also disallow caching.
I believe the reason is that we have different code for preloading resources, once in the base class Benchmark:
The Wasm runner(s) (both the new
WasmEMCCBenchmark
and theWasmLegacyBenchmark
) do an unnecessary second request/fetch for resources inplan.preload
. See attached screenshot, for example withgcc-loops-wasm
:In most cases, browsers will fulfill the second request from the cache (as it is here), but we should still clean this up. A naive or misconfigured web server could potentially also disallow caching.
I believe the reason is that we have different code for preloading resources, once in the base class
Benchmark
:JetStream/JetStreamDriver.js
Line 777 in 4352dab
and once again in the Wasm benchmark classes
JetStream/JetStreamDriver.js
Line 1137 in 4352dab
It seems the latter should reuse the former, which also would get rid of some code duplication.
Any subtlety or underlying reason I am missing why this second preloading mechanism is there?
The text was updated successfully, but these errors were encountered: