Hi Daniel,
This feature has no impact without the Wasm moduled specifically compiled
for it. So we are dependent on partners implementing this and measuring the
impact. We have concrete plans with Google Sheets to run A/B trials based
on an origin trial, but hope that other partners like Kotlin or Dart would
follow soon to provide more data points.
Best regards,
Emanuel
On Wed, Sep 13, 2023 at 5:48 PM Daniel Bratell <bratel...@gmail.com> wrote:
> Do you plan to run it as a finch experiment or do you have partners
> prepared for an Origin Trial?
>
> /Daniel
> On 2023-09-12 21:24, 'Emanuel Ziegler' via blink-dev wrote:
>
> 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 emails ecmzieg...@chromium.org, jkumme...@chromium.org,
> ad...@chromium.org
>
> Explainer None
>
> 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 component Blink>JavaScript>WebAssembly
> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EJavaScript%3EWebAssembly>
>
> TAG review None
>
> TAG review status Not 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://flags None
>
> Finch feature name None
>
> Non-finch justification None
>
> 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
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPAU7RyzxKa0Pj6q7B_jyfT%3DH%2BSK264%3Dx8wn1ans%3D8UjHRhctQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
>
--
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/CAPAU7Rym1c7E0Da82c8f3PKOac5hdTPQ1F575xjvfnuKEAD0cg%40mail.gmail.com.
