The baseline electron app can be found here: https://github.com/jrieken/electron-startup-perf-baseline

related to #15455

Can you put the timings for vanilla vs code side-by-side on a table, along with their relative difference? Makes it easy to reason about things.

The following are some operation we perform that take long, like spawning a process or listening on a port

• getHttpCommonHeaders will eventually reach into getmac which execs a process blocking for ~15ms, depending on virus scanners longer
• spawning the shared process, like above is blocking for some millis
• setupIPC takes ~5ms for starting to listen

The startup logic should be optimised to start loading workbench.main.js as soon as possible. That is because it takes quite some time (~800ms) to complete and we should run all other operations in parallel to that and not sequentially, prior to it

Would it not be possible to wait creating the shared process until the first window is loading? All shared process related methods are promises anyways and it seems ok to wait until a window is visible.

Now that we look into moving the shared process into a real Electron window, I fear that startup would even get slower compared to just spawning a process.

For the setJumpList call, I simply wait for the first window via win.webContents.on('did-start-loading',...)

Yes - we are moving the shared process into a browser window to begin with and should then also be able to make it after the first, user-windows started loading: #22091

fyi - I have moved waiting for the ready-state into the main.ts such that we at least load the loader and code while waiting

is there any further progress here @jrieken since you apparently started working on it?

I've changed the getCommonHttpHeaders thing to simply use a UUID which we store after generating it. Getmac won't be called anymore. Unfortunately this is still happening on startup in a sync fashion. The reason for this is that we don't have an atomic storage mechanism across all processes. If we don't generate it sync on startup, we might have 2 processes generating 2 different UUIDs. The mitigation for this is to use a single machineid file for this in user data. This will make reading and writing to this file extremely fast.

@jrieken setupIPC is a hard nut to make faster. We use sockets/named pipes to make sure we don't execute two instances at the same time. Do you know of anything else that has the same atomic properties yet is faster?

Do you know of anything else that has the same atomic properties yet is faster?

Yeah, no real clue. The good news is that I haven't seen it take much longer on other machines. So in contrast to launching (part of getmac) which can take a second on some machines this seems to be more or less constant. Ok for me to leave it as is

Cool, let's close it!