Performance around Client call to backend

[NathanielPrescott]

I asked a similar issue on the wasm-bindgen github. But after figuring out how to use a timer in the frontends WASM service I found that the 'Client' call to the backend with grpc was exponentially slower than making a REST call. Below is my original message that I posted to the wasm-bindgen discussion. I was wondering if anybody knows of any issue related to performance when making calls to a backend from a WASM service on the client. Currently I am working on making another non-wasm service to call my backend to verify what the correct timing should be. I've just finished this and the other rust client is returning the message calls around 1.2ms and the Small Image calls in 1.3ms.

Hello, I have a question around wasm-bindgen and how WASM works in general. I currently have a project where I am testing the performance of REST and gRPC from a web client. This project is open source on github (https://github.com/NathanielPrescott/Performance) and I am running it locally. I have noticed a few things that I currently don't fully understand. If I make a call to a basic function on my clients WASM service that returns a String then it will take around 0.1ms or less time per call. When I make a REST call to my service, where I am returning a reduced quality Image (Small 0.55Mb), the response returns in around 1.5ms. While when I make a call with the same image via my gRPC WASM service I find that the call takes on average 5.9ms which is dramatically slower. This timing issue gets exponentially worse for the higher resolution images. I found that I can't perform any timing testing within the gRPC WASM service due to some WebAssembly limitations, if I'm wrong about this please let me know. As I was looking into the gRPC WASM service, with Chromes network tab, I found that the call for the Small GetImage gRPC call is being done in around 1.3ms which is much closer to what I would expect this to take. Is this expected for WASM calls to be doing extra things in the background that slow down responses or is this an issue where WASM is struggling with converting the response to a JS format? The image is a Vec in rust and then gets converted to a Uint8Array for javascript.

I am currently learning Rust and very interested in using WASM with it so wanted to use this project as my first learning experience outside of reading the book. If this issue would be better posted on the github wasm-bindgen issues or if this is another issue not related to wasm-bindgen then please let me know. Thank you for your time.

[devashishdxt]

I'm not an expert on WASM and its implementation in browsers either. But, in general, there's an overhead of using WASM in browsers especially when you want to interact with DOM or make any network calls (as all the values needs to be copied from WASM to JS). The current implementation of grpc client on browsers uses fetch internally and on top of that, there's an overhead of transferring values from JS to WASM and deserialising the response in WASM. If you want to get more granular timings, you can clone this repo and add few tracing points in the code to know which part is taking most of the time.

Also, please don't forget to share your findings as this may help us to improve performance further.

[NathanielPrescott]

I will for sure share my findings, once I figure out how to use this downloaded repo as a crate instead of the one from crates.io I will get back to you with my findings. My purpose for the gRPCvsREST project is to create an open example of a very specific web based use case that helps others.

[NathanielPrescott]

From working in your project and the timings associated I've found that it looks like these calls are being made with HTTP1.1 and due to the fetch the values are being converted like you said. I think I was hoping for a more internalized tool that did not have to rely on the JS fetch and could call the service I had directly with HTTP/2. I appreciate the help and if I see anything further I will open up a PR or an issue with the specifics.