Feature: scheduling API for main process

[deepak1556]

Similar to the renderer variant https://chromestatus.com/feature/6031161734201344 using the browser UI thread scheduler.

Need arised from microsoft/vscode#159650

[Prinzhorn]

This sounds overly complicated when the docs state that you should

under no circumstances block this process and the UI thread with long-running operations. Blocking the UI thread means that your entire app will freeze until the main process is ready to continue processing.

https://www.electronjs.org/de/docs/latest/tutorial/performance#3-blocking-the-main-process

That means

we schedule a large amount of work right after the loadUrl call for a BrowserWindow assuming that we can schedule work parallel to the window opening

is a design flaw that doesn't fit the limitations of Electron. Or am I misunderstanding what's being proposed?

I personally have my entire application logic in a worker thread and the main process handles nothing but windows and menus (things that require the electron import). Most communication happens directly between renderer and worker (HTTP, WebSockets or EventSource), because every single IPC call between main and renderer (serialization / deserialization) will introduce tiny janks (scrolling, animation, etc.) in every browser window.

Edit:

provide an API or event that can signal us in the main process that now is a good time to work on something

My point was that from my experience it's never a good time to do work in main at all. And with multiple windows this problem will become so complex that such an API might improve the perceived performance, but can never solve the underlying issue. Which is that Electron's architecture does simply not allow doing anything in main.

[deepak1556]

Nope the feature request is different from the linked issue. It is not about Electron providing signals for applications to schedule expensive work but the other way, allowing applications to reuse the main process scheduler to break up user tasks in the main process similar to https://docs.google.com/document/d/1Apz-SD-pOagGeyWxIpgOi0ARNkrCrELhPdm18eeu9tw/edit?usp=sharing

Since the main process is responsible for lot of jobs around rendering, input, loading, navigation etc it is not possible for it to know the priorities of applications and given V8 execution in the main process, applications can easily perform long running tasks. But the scheduler in the process knows how and when to handle the different types of tasks and we already use it for some of the Electron API implementation.

[Prinzhorn]

Nope the feature request is different from the linked issue

Ok I see, thanks for clarifying. I think no amount of scheduling and prioritization will prevent expensive work from blocking main. At least that's how I understand it. It might allow us to execute it in a slot that causes less jank. I assume all the things that Electron/V8 are doing are carefully orchestrated and predictable to allow a smooth experience. But the things users do in main are not and most users shouldn't even have to think about that (while all users want a fast app).

It is not about Electron providing signals for applications to schedule expensive work but the other way, allowing applications to reuse the main process scheduler to break up user tasks in the main process

It might be because I'm not a native speaker, but to me these things sound identical or the difference is very technical. The end result is that users can schedule their own processing to happen in main at a different point then "now". Correct?

allowing applications to reuse the main process scheduler to break up user tasks in the main process

I'm sure there are expensive tasks that cannot be broken up further and need to be done in one shot. Hence my conclusion that it will cause less jank, but not eliminate it. But I definitely don't know enough about the internals to add anything else to this discussion. I'm just very interested in anything performance related. As a user of Electron I learned to leave the main process alone and I will continue to do so.

[deepak1556]

At the moment, I cannot answer whether this API will actually help with improving the responsiveness of the main process or not. This issue is mainly an idea I wanted to try prototyping after coming across the web scheduler API today. I will update here as I get some results.

#34980 is actually a way for an application to delegate work done in the main process to a utility process and still have the ability to communicate directly with a renderer. But there are some work that can only be performed in the main process and I want to see if that can be improved.