commit 9b11bf4da9e006da8da03d629edc11fb79a6fefb
author Martin Kustermann <kustermann@google.com> Mon Dec 16 00:55:26 2024 -0800
committer Commit Queue <dart-scoped@luci-project-accounts.iam.gserviceaccount.com> Mon Dec 16 00:55:26 2024 -0800
tree 50a745b3d1ae87ee8cec4628493fa3106880732a
parent e8ebee884553828044abc53d40e389691e0a384a

[dart2wasm] Take advantage of fast `js-string` builtins

Some wasm engines have started to optimize the `js-string` builtin
proposal (e.g. V8) and those that haven't yet are probaly going to
do soon.

So we can start taking advantage of it in dart2wasm.

=> We make use of them in the JS<->Dart string copy code.

=> This will also provide a better baseline when evaluating whether
   switching to JS stringes entirely makes sense.

A somewhat unrelated (but necessary for this CL) change is to tighten
the types we use in `@pragma('wasm:import')` and
`@pragma('wasm:export')` in some cases:

We should only use 'pure' wasm types (i.e. not wasm struct / function
types we define for dart classes & functions) and mostly non-composed
types in import/exports as the `--closed-world` optimizations from
binaryen rely on that (and error otherwise).

Overall this leads to significant improvements in Dart<->JS
string copies.

The `WasmDataTransfer.*{From,To}BrowserString` benchmarks
improve something between 50-100%.

Change-Id: I2048113c462ecb2047402c0616d2b3b1f45773f5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/400641
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>