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]

I tried using WebSocket based on 127.0.0.1 instead of the invoke function, and the result was surprising:
In the case of low CPU load, the invoke function communication delay is 3-16ms, and the WebSocket delay is about 2ms. During CPU performance testing (with a load close to 100%), the invoke function delay can exceed 250ms, while the WebSocket delay remains within 30ms.

This seems a bit counterintuitive. In theory, shouldn't WebSocket consume more resources and have higher latency? Why is there such a big gap between the two (I only replaced the communication part, without changing the business logic)?

[Think-M]

Further testing showed that by using local loopback WebSocket (including encryption) instead of invoke, CPU usage was reduced by 3%, and real-time performance was significantly improved under CPU overload conditions (2000ms>20ms).

This makes me wonder if there may be unknown performance issues with Tauri's invoke communication on Windows?

If not, I think the Tauri team could consider using local loopback WebSocket as another cross platform, high-speed, and stable communication method between Rust and webview, and between webview and webview. The cost is just occupying one port.