Investigate connection with top-level await about esm-integration HOT 9 CLOSED

OK, if we do want to keep them well-ordered, then the actual requirement is a little more subtle: We should start instantiation as soon as the dependencies (which might export types) are available, and then execute the start function exactly in order, based on the same sibling ordering that JS modules have. This means we need a sort of synchronization barrier in the middle of the WebAssembly instantiation algorithm.

from esm-integration.

Sounds like we are on the same page. In particular, the compilation work can be done ahead of time even in platforms that do that compilation as part of their instantiation API.

I think we all agree that startup should be fast, and just have different theories about how long this pause would be. What should be our next steps to getting data on this question?

from esm-integration.

Wasm compilation will be done in parallel and the instantiation on the main thread (actually blocking it).

We need to make sure that the ordering is respected, given that compilation times are variables it will require a bit of bookeping, but the module graph will indicate the order.

Note that wasm modules with no dependencies can be instantiated (including the start func evaluation) in any order (we do this already in Webpack).

from esm-integration.

Note that wasm modules with no dependencies can be instantiated (including the start func evaluation) in any order (we do this already in Webpack).

This is a design question: Do we want to allow implementations to execute the start function in any order, or should this be deterministic based on the ordering of the imports that led to its use? ESM+HTML makes this deterministic for JS, I believe.

from esm-integration.

They SHOULD be deterministic and ordered, because they can cause side-effects. You can run any JS function during the start.

from esm-integration.

We should start instantiation as soon as the dependencies (which might export types) are available

As the order of the dependencies is also defined the same way, this leads to no optimization:

- a.js
  - x.wasm
    - b.js
    - c.js
  - y.wasm
    - d.js
    - e.js

The execution order is:

b, c, x, d, e, y, a

The dependencies are exactly at the time available when execution should happen. You can't start instantiation earlier. You can't order the dependencies of wasm modules because they could have side-effects and their execution order is well defined.

There actually is an edgecase where you could start instantiation earlier, but that is very rare: All dependencies of the wasm module are referenced by some modules earlier in the graph, like this:

- a.js
  - d.js
  - e.js
  - x.wasm
    - b.js
    - c.js
  - y.wasm
    - d.js
    - e.js

d, e, (y instantiation), b, c, x, y start function, a

But this is too rare to make any difference.

=> When running instantiation while evaluation phase it will cause sequential instantiation of wasm modules. => Bad for performance

from esm-integration.

@sokra If we schedule the heavy parts of instantiation (chiefly, compilation) ahead of time, are you still worried about the startup time impact? Can you think of any benchmarks/simulations we could do to assess the impact now while we are in the design phase?

from esm-integration.

Downloading and compiling can be done at any time in any order because that isn't causing any side-effects.

Instantiation must respect the order, as said before.

from esm-integration.

The current specification is in terms of the top-level await proposal, so this issue can be closed.

from esm-integration.