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
When we replaced the asm.js image decoder with a WebAssembly-based one (#20), we gained performance and resilience† at the expense of increased bundle size and breaking compatibility. This was fine for our use case--but what if people want to use our library in a runtime that does not support WebAssembly (or asm.js for that matter)? What if bundle size is critical?
† asm.js is dead tech and there are development tools (e.g. esbuild) that do not support it. See #20 (comment)
In our internal experiments, a properly optimized vanilla JS decoder was ~15% slower in Chrome (V8), and ~50% slower in Firefox and Safari. Since Node.js uses V8, we may expect similar performance differences in Node.js. These differences may be acceptable to those who want a tiny bundle--or don't have the luxury of WebAssembly.
Perhaps we could provide two decoders (vanilla JS and WebAssembly) and let the user choose?
Brainstorming Strategies
Create separate bundles for vanilla JS and WebAssembly, possibly exposing them as separate endpoints:
pastelmind
changed the title
Investigate providing separate parsers for pure-JS and WebAssembly
Investigate providing both WebAssembly- and vanilla JS-based decoders
Sep 27, 2022
We might be able to bundle asm.js code while still supporting esbuild (or Vite) by wrapping the asm.js code in an indirect eval (or a Function constructor). Code transformers usually leave string literals as-is.
It would make the code slightly larger (and complicate the build pipeline) but it could work.
When we replaced the asm.js image decoder with a WebAssembly-based one (#20), we gained performance and resilience† at the expense of increased bundle size and breaking compatibility. This was fine for our use case--but what if people want to use our library in a runtime that does not support WebAssembly (or asm.js for that matter)? What if bundle size is critical?
† asm.js is dead tech and there are development tools (e.g. esbuild) that do not support it. See #20 (comment)
In our internal experiments, a properly optimized vanilla JS decoder was ~15% slower in Chrome (V8), and ~50% slower in Firefox and Safari. Since Node.js uses V8, we may expect similar performance differences in Node.js. These differences may be acceptable to those who want a tiny bundle--or don't have the luxury of WebAssembly.
Perhaps we could provide two decoders (vanilla JS and WebAssembly) and let the user choose?
Brainstorming Strategies
Create separate bundles for vanilla JS and WebAssembly, possibly exposing them as separate endpoints:
Create two
parse()
methods and export them:Create two
composite()
methods:The text was updated successfully, but these errors were encountered: