Improve the real-time performance of the invoke function

[Think-M]

On Windows, I have set the priority of the Rust process and the WebView process to real-time level respectively.
After testing, it was found that within these processes, even when testing the CPU with performance testing software, the real-time performance is still very good (with a worst-case delay of only a few tens of milliseconds).
But once the function 'invoke' is used for communication between webview and rust, the delay can even reach over 500ms.

I feel like I'm very close to success, but I don't have any ideas for improvement. I would like to ask:

1. If we continue to use function 'invoke', do you have any suggestions for improvement?
2. Does the communication function 'invoke' between the Rust process and the WebView process depend on other processes?
3. If the function 'invoke' is not used, is there an alternative solution with better real-time performance?

The project is about to go live, and I urgently hope to solve this problem. Looking forward to your insights! Thank you !

[FabianLars]

1. Limit the amount of data you send as much as possible 🤷
2. We can't see the inner working of webview2 either but ideally only the webview2 processes are involved here.
3. You'd think we'd use that one then :P There are 2 webview2 apis you may wanna look into (there's nothing in tauri that would help you use them):

• https://learn.microsoft.com/en-us/dotnet/api/microsoft.web.webview2.core.corewebview2.addhostobjecttoscript?view=webview2-dotnet-1.0.3351.48
  • Probably slow for large-ish amount of data (will block the ui i think)
• https://learn.microsoft.com/en-us/dotnet/api/microsoft.web.webview2.core.corewebview2.postsharedbuffertoscript?view=webview2-dotnet-1.0.3351.48
  • shared memory is hard to use well and secure. i've also seen negative feedback about its performance from plain webview2 consumers (which sounds weird to me for shared memory)

[Think-M]

https://learn.microsoft.com/en-us/dotnet/api/microsoft.web.webview2.core.corewebview2.postsharedbuffertoscript?view=webview2-dotnet-1.0.3351.48

• shared memory is hard to use well and secure. i've also seen negative feedback about its performance from plain webview2 consumers (which sounds weird to me for shared memory)

@FabianLars
Regarding the performance issue you mentioned, do you have any relevant links? I speculate that it might be due to the use of postMessage or the repeated creation of shared memory, which introduces additional overhead (I don't know if this is related, but I would like to learn more about it. I am also planning to use shared memory)
Looking forward to your reply!

[FabianLars]

No links right now. I mostly just went through the webview2feedback repo (plus one or two DMs) 🤷 afaik post message wasn't in play.

Would love to hear about your experience with it, especially if it's in the context of a tauri app.

[Think-M]

No links right now. I mostly just went through the webview2feedback repo (plus one or two DMs) 🤷 afaik post message wasn't in play.

Would love to hear about your experience with it, especially if it's in the context of a tauri app.

I tested using shared memory(build a circular buffer zone) on Tauri today and compared it with websocket and invoke functions.

Both the shared memory scheme and the websocket scheme show good stability under high CPU usage, but the latency of invoke still fluctuates greatly.

However, for shared memory solutions, how to efficiently notify the other party that a message has been delivered is a challenge. I use polling to query memory flags, but on Windows, if the system time slice is not adjusted, the delay accuracy is only about 15ms, and on webview, the delay accuracy is also about 5ms. Therefore, the bottleneck is not shared memory, and the polling delay accuracy. In the worst case, the round-trip communication time may exceed 20ms. I adjust the system time slice to around 1ms through timeBeginPeriod, and the round-trip communication time is reduced to 1ms~9ms (which may be even better, as most of the time is spent on the polling delay function).

If there is a way to combine shared memory with event notifications, it may be perfect, but Tauri's event system invoke function is very sensitive to CPU usage, which makes me not have much confidence in the performance of Rust sending events to webview2.

What underlying interface is used for communication between Tauri and webview2? Perhaps I can also test the situation in conjunction with the event system.

[Think-M]

@FabianLars
By combining shared memory (CreateSharedBuffer) and message notifications (PostWebMessageAsString, add_TebMessage Received, chrome.webview.postMessage, etc.), the round-trip communication latency can be reduced to around 0.5ms.

In my opinion, there have been no performance issues with using shared memory communication, and postMessage has decent performance, making it suitable for message notifications of shared memory changes.

I feel that Tauri's invoke communication is much slower compared to two postMessages, and it is even worse under high CPU usage (even up to thousands of ms). Why is this happening?

[TomieAi]

The first call is always the highest, and it gradually speeds up. If you run it again, the same pattern occurs. I thought my code was slow like, there’s no way a ping should take 1-10 ms 😆but it turns out it’s like that by design.

Take note: it’s only going to speed up if you call it multiple times in a row. If you just invoke it one at a time, you’ll always get 9-10 ms as the base latency.

TypeScript

    results: [number, number][] = [];
    count = 0;

    runOnce(max: number) {
        const start = Date.now();
        invoke<number>("ping")
            .then((rustTime) => {
                const end = Date.now();
                this.results.push([rustTime - start, end - start]);
                this.count++;
                if (this.count < max) {
                    this.runOnce(max);
                } else {
                    console.log(JSON.stringify(this.results));
                }
            })
            .catch((err) => console.error("Latency test error:", err));
    }

Rust

#[tauri::command]
fn ping() -> u128 {
    SystemTime::now()
        .duration_since(UNIX_EPOCH)
        .expect("Time went backwards")
        .as_millis()
}