LGTM for an origin trial M119-M124 (which I think is what you requested)
Good luck with your data collection!
/Daniel
On 2023-09-13 18:04, 'Emanuel Ziegler' via blink-dev wrote:
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
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPAU7Rym1c7E0Da82c8f3PKOac5hdTPQ1F575xjvfnuKEAD0cg%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/47b333e5-e707-2d88-9d6d-bd30a5bf20f7%40gmail.com.
