Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WASM] Reintroduce shared memory buffer #53

Closed
Tewr opened this issue Jul 29, 2019 · 1 comment · Fixed by #59
Closed

[WASM] Reintroduce shared memory buffer #53

Tewr opened this issue Jul 29, 2019 · 1 comment · Fixed by #59
Assignees
Labels
enhancement New feature or request

Comments

@Tewr
Copy link
Owner

Tewr commented Jul 29, 2019

Up until preview6, the blazor filereader Wasm library used unmarshalled calls to communicate the file chunks from js to .net. This is no longer the case due to a breaking change in blazor(mono?) that broke the implementation. Might be something as simple as a name change in the API, have not investigated thoroughly.

Main motivation of reintroducing this thing is speed (~30% faster) and general memory / cpu usage (not really benchmarked though current marshaled memory usage should at minimum the be 2.4 * buffer size compared to unmarshalled)

First issue is how to re-implement the method.
The original implementation passed a reference to a byte array to js in the first call. Current implementations doing about the same thing (ex http message handler in blazor) rather have a call originating from js to allocate and get a reference to that array, which could be considered being the reference implementation.

Second issue, how to enable usage of the method..
As there is still no WASM target for libraries, an initialization option has to be added that enables referencing MonoWebAssemblyJSRuntime.InvokeUnmarshalled<...>. I'm a little bit unhappy about making end-users do that this as it makes setup quite complex. Might be possible with a simple boolean option but that would cost a lot in reflection instead.

@Tewr Tewr added the enhancement New feature or request label Jul 29, 2019
@Tewr
Copy link
Owner Author

Tewr commented Aug 2, 2019

After taking the time to read Blazor's http.ts and WebAssemblyHttpMessageHandler.cs thoroughly, I think there is a big possibility to avoid using MonoWebAssemblyJSRuntime.InvokeUnmarshalled altogether, this is good news. For library users, a boolean should be enough (platform detection is thus delegated to the setup procedure, something like options.UseWasmSharedBuffer = true).

The strategy should be to re-introduce a Task-queue of callbacks for passing back the array (instead of the very comfortable await InvokeAsync() -> result, use await InvokeAsync() -> void and TaskCompletionSource just like dispatchResponse calls WebAssemblyHttpMessageHandler.ReceiveResponse.

While WebAssemblyHttpMessageHandler is using InvokeUnmarshalled to pass a byte array to js, in my case there is no need to pass anything, only the response is interesting, thus referencing MonoWebAssemblyJSRuntime can be avoided.

@Tewr Tewr changed the title Reintroduce unmarshalled interop [WASM] Reintroduce shared memory buffer Aug 2, 2019
@Tewr Tewr self-assigned this Aug 14, 2019
@Tewr Tewr closed this as completed in #59 Aug 14, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant