Batch calls to DOM API to reduce the overhead of JS calls

[ranile]

The slowest part of Yew right now is the calls made to DOM, on every render. Until Web Assembly Interface Types Proposal is implemented, the calls to DOM APIs are made by using WASM imports. API bindings are provided by crates like web-sys and js-sys by using core APIs exposed by wasm-bindgen.

Calling these APIs have a cost, much higher than calling the same API directly from JavaScript. Given the amount of API calls we make during a render, these calls add up very quickly. We should:

• Try to reduce the number of JS calls
• Batch the calls

How to batch the calls?

During reconciliation of DOM, we follow the following procedure:

1. When a call is to be made, instead of making the call, it should be stored in a cache.
2. At the end of reconciliation, a function imported as JS-snippets is called and the list of calls to be made are passed to it.
3. This function makes the DOM API calls and returns the results.
4. Those results are consumed in Rust
   This way, we should be able to avoid a large number of DOM API calls.

Considerations

Calling the JS function that performs the DOM manipulations and passing/receiving data from JS has a cost. We can alleviate the costs by:

• Keeping the amount of calls to this function low
• Instead of directly passing data to/from JS function(s), we may use shared memory. We can write an ArrayBuffer from Rust/JS and read it from JS/Rust. It could save us the cost of us passing around large amounts of data as parameters

Related

Discord discussion

Message link

@hamza1311
what if had a JS module that exported functions which made all the calls to DOM APIs? We make multiple JS calls consecutively while rendering. By wrapping those calls in a JS module, we can reduce the number of external calls
How does it sound?
@WorldSEnder
Is it really that expensive? Since those calls are just done once (nobody should use more than a handful of portals, really), and reconciliation of the DOM is much more expensive, I don't think it matters.
@hamza1311
even when reconciling, we still have to make calls to JS
@WorldSEnder
yeah those deserve some care, right
@hamza1311
if we could ensure we make only 1 call, that should improve performance
@WorldSEnder
we still have to marshall a lot of strings from rust to js
@hamza1311
i'm thinking of a queue where all the calls are stored by VDOM and then passed to a JS function
@hamza1311
SharedArrayBuffer?
@WorldSEnder
you mean build a custom StringTable and marshall them all at once that way?
@hamza1311
yeah, send them all in a single go
1 call per render
@WorldSEnder
hm, do we care about IE11 and Opera Mobile?
@hamza1311
no
@fxrysh
why should we
@WorldSEnder
cause https://caniuse.com/sharedarraybuffer says that's at only 81% support :/
but other than that, I like the idea of batching DOM calls. Start a command buffer and retire it at the end of the scheduler, kind of like OpenGL calls?

Also see

• Shared memories
• WebAssembly.Memory
• ArrayBuffer
• SharedArrayBuffer