3 ms·

Images aren't as expensive as critical-path code as we (the browser) parse and raster them off-thread. Outlined some of the costs here: https://infrequently.org

Images aren't as expensive as critical-path code as we (the browser) parse and raster them off-thread. Outlined some of the costs here: https://infrequently.org/2017/10/can-you-afford-it-real-world-web-performance-budgets/ https://infrequently.org/2017/10/can-you-afford-it-real-worl... Excited to see how much smaller a good linker can make this.

pjmlp 8y ago
JavaScript JIT compilers also don't compile everything on one go. I can easily imagine asynchronous compilation of Web Assembly modules in background threads as its use increases.
- slightlyoff 8y ago
  WASM streaming compilation is possible today and runtimes are adding tiered compilers: https://v8project.blogspot.com/2018/08/liftoff.html https://v8project.blogspot.com/2018/08/liftoff.html Regardless, as long as you're network-bound in the critical-path, that will only help to the extent that partial execution works well. That is baked into HTML/CSS/JS; not so much with WASM.
  - dikaiosune 8y ago
    How is partial execution baked into JS? IIUC, my whole JS file is fully parsed an resolved before it is evaluated. If you're referring to the use of multiple files for parallelism here, then the obstacle there is not wasm itself but the work that's still in progress to define a dynamic linking story for it. I'd point out that the need for better dynamic linking to enable lower TTI is also a problem faced in the bundling/tooling heavy JS community.
    - slightlyoff 8y ago
      JavaScript can be evaluated top-level function by top-level function and file-by-file, modulo variable hoisting. You can create situations where everything is blocked, but that's not the norm.
      - dikaiosune 8y ago
        Do you have numbers for how much of the web avoids variable hoisting? How much of the web has more than one top-level fn per file? Do these numbers shift significantly between different toolchains or methods of delivering JS?
dikaiosune 8y ago
It would be interesting to try for some apples-to-apples comparisons for the parse and initial exec time of js vs wasm. The latter was designed with the goal of streaming validation and compilation, js needs to have a lot of work done before it can load. Which strongly suggests to me that intuitions about KBs-of-JS vs KBs-of-Wasm are likely to be wrong, especially as the state of wasm implementations improves.

pjmlp 8y ago

JavaScript JIT compilers also don't compile everything on one go. I can easily imagine asynchronous compilation of Web Assembly modules in background threads as its use increases.

slightlyoff 8y ago
WASM streaming compilation is possible today and runtimes are adding tiered compilers: https://v8project.blogspot.com/2018/08/liftoff.html https://v8project.blogspot.com/2018/08/liftoff.html Regardless, as long as you're network-bound in the critical-path, that will only help to the extent that partial execution works well. That is baked into HTML/CSS/JS; not so much with WASM.
- dikaiosune 8y ago
  How is partial execution baked into JS? IIUC, my whole JS file is fully parsed an resolved before it is evaluated. If you're referring to the use of multiple files for parallelism here, then the obstacle there is not wasm itself but the work that's still in progress to define a dynamic linking story for it. I'd point out that the need for better dynamic linking to enable lower TTI is also a problem faced in the bundling/tooling heavy JS community.
  - slightlyoff 8y ago
    JavaScript can be evaluated top-level function by top-level function and file-by-file, modulo variable hoisting. You can create situations where everything is blocked, but that's not the norm.
    - dikaiosune 8y ago
      Do you have numbers for how much of the web avoids variable hoisting? How much of the web has more than one top-level fn per file? Do these numbers shift significantly between different toolchains or methods of delivering JS?

dikaiosune 8y ago

It would be interesting to try for some apples-to-apples comparisons for the parse and initial exec time of js vs wasm. The latter was designed with the goal of streaming validation and compilation, js needs to have a lot of work done before it can load. Which strongly suggests to me that intuitions about KBs-of-JS vs KBs-of-Wasm are likely to be wrong, especially as the state of wasm implementations improves.