Dear API Owners,
Many use cases for WasmGC require calling JS functions or WebAPIs frequently. These calls suffer from substantial overhead when strings are involved due to the encoding/decoding required for changing in between the non-standardized Wasm module representation and the engine-internal JS string representation. We previously evaluated native string operations in Wasm <https://github.com/WebAssembly/stringref/blob/main/proposals/stringref/Overview.md> which would map to JS equivalents and use the same backend, eliminating the need for re-encoding and copies. While the performance of this approach was excellent (see e.g. Kotlin/Wasm's DBMonster benchmark with <https://zal.im/wasm/dbmonster-stringref/> and without <https://zal.im/wasm/dbmonster/> stringref), the Wasm Community Group preferred an alternative solution that uses imported JS functions <https://github.com/WebAssembly/js-string-builtins/blob/main/proposals/js-string-builtins/Overview.md> for creating and manipulating strings which could then be optimized away by the engine. Our experiments show a similar peak performance but slightly lower performance on startup as Liftoff is not capable of doing such optimizations effectively falling back to executing the call. We would therefore like to launch a 6-month origin trial starting in M119 for comparing the two approaches and, if performance is good enough, encourage partners to switch over to the new proposal to verify its viability. Contact emailsecmzieg...@chromium.org, jkumme...@chromium.org, ad...@chromium.org ExplainerNone Specification https://github.com/WebAssembly/js-string-builtins/blob/main/proposals/js-string-builtins/Overview.md Summary This feature exposes common JS string operations for easy import into WebAssembly and optimizations thereof. This allows creating and manipulating JS strings from WebAssembly without native support within WebAssembly while still allowing for a similar performance as native string references. The mechanism works by exposing suitably strict versions of JS string operations in the WebAssembly JS API. These can be imported by modules using externref as a generic data type for storing the strings. The engine can identify that these imports can be represented by native graph operators without the need for calling into JS. This leads to a comparable peak performance as native string operations while allowing quick interoperability with JS since no copying at the boundary is required when calling into arbitrary JS functions that consume strings. Blink componentBlink>JavaScript>WebAssembly <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EJavaScript%3EWebAssembly> TAG reviewNone TAG review statusNot applicable Risks Interoperability and Compatibility None *Gecko*: Positive *WebKit*: No signal *Web developers*: No signals *Other signals*: WebView application risks Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications? None Goals for experimentation Ongoing technical constraints None Debuggability None Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?No Is this feature fully tested by web-platform-tests <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> ?No Flag name on chrome://flagsNone Finch feature nameNone Non-finch justificationNone Requires code in //chrome?False Estimated milestones No milestones specified Link to entry on the Chrome Platform Status https://chromestatus.com/feature/6695587390423040 -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPAU7RyzxKa0Pj6q7B_jyfT%3DH%2BSK264%3Dx8wn1ans%3D8UjHRhctQ%40mail.gmail.com.
