Investigating Electron 8 exploration startup performance #97638
Comments
deepak1556
added
engineering
Summary: BEST Summary: BEST |
|
Couple of things to confirm,
Atleast from my numbers |
|
@deepak1556 the |
|
Ah ok, thanks for clarifying! |
The "standard start" is defined as a workbench state that shows the explorer viewlet and a single file - the perf machines use the vscode-folder and open the package.json-file. Setting up this state is a manual process but maybe with @eamodio's state for codespaces this can now be automated? |
|
Since we show the explorer by default, I would think that running |
Need to give that a try again. On the actual numbers @bpasero Didn't you also measure electron 8 performance? Can you share your numbers here? |
This works! I am changing the perf script args to get new numbers now. |
|
Actually, this can be reproduce way simpler, use bare electron fiddle. Use the snippet below (
I am seeing the following numbers
I conclude the version 8.2.5 is roughly 10% slower which somewhat correlates with the numbers the mac perf bot is showing // This file is required by the index.html file and will
// be executed in the renderer process for that window.
// All of the Node.js APIs are available in this process.
function fib(n) {
if(n === 0) {
return 0;
} else if(n === 1) {
return 1;
} else {
return fib(n-1) + fib(n-2);
}
}
const t1 = Date.now();
console.log(fib(42));
console.log(`DURATION ${Date.now()-t1}ms`) |
|
I ran tests on macOS, here are my findings: Stable Cold Stable Warm Exploration Cold Exploration Warm |
|
I ran similar tests on Windows but cannot find the reports I did anymore. I think I was seeing similar numbers, slightly slower between the runs but for sure not as bad as the perf machine shows. But then again, this is also a very fast machine. |
|
Related blog entries for V8 changes: I wonder if the pointer compression would have any impact. |
|
New perf script numbers based on macOS windows Now the number is consistent on macOS with your observations :)
Good question! but electron disabled pointer compression until v9 due to compatibility issue from node.js electron/electron#21468 |
|
I will skip windows side for now, since I can't repro the issue there. Will continue investigation on macOS tomorrow. One thing to note for the fiddle test, if you replace |
|
using the test sample from @jrieken in a base electron app, start with
This will generate Interesting trace slices
sandbox
nodeIntegration
So the node context initialization path is negligible, we can ignore it. The bulk of delay stems from the v8 execution which matches the number we see on the devtools console and not from any renderer startup stuff in electron. start with |
|
Tried to visualize v8 stuff from Node.js profiler, again the v8 impact is seen here and matches the above observation. 8.2.5 [Summary]:
[JavaScript]:
7.2.4 [Summary]:
[JavaScript]:
|
|
Working on getting a flamegraph for the v8 execution path. |
|
Built d8 (simple commandline for v8) of Electron
cpuprofile and perf map The stack is incomplete on macOS, will have to try on linux with perf tool which is known to work well. |
|
Perf numbers on Windows for me: Electron 7 Insiders COLD WARM RELOAD Electron 8 Exploration COLD WARM RELOAD It seems to me that cold startup is indeed slower, but otherwise I was not able to measure any difference. This is with |
|
idk what's up with the perf machine. @alexdima brought up the idea that it might be a new set of CPU instructions used by electron 8 that can only be emulated on the perf machine - it is a very old machine (7+ years)... |
|
I'm seeing VERY long opening times on my Windows 10 (2004 - slow ring, 19041.264) desktop machine (12-core 3.8GHz AMD proc) with the latest insiders too. |
|
Went back to the drawing board, redid the measurements for windows.
As seen above, the main process is pretty much blocked by something on the UI thread, so rules out any impact from chromium, rather something from app javascript is responsible.
Turns out all the IO calls in the app are comparatively slower to the measurements from Electron 7 After that it was just a matter of bisect to find the offending commit and electron/electron#20303 seems to be the root cause. Double verified by applying this patch to Electron 7 and the cpu profile numbers now match Electron 8. Next step would be to create a minimal repro. |
|
Results from running perf tests on Windows 10 VM (macOS, Parallels), comparing current insiders to stable: |
|
Results from running perf tests on my office laptop (Windows 10, Parallels) including Electron 9 numbers: |
|
@deepak1556 Is there anything I can record on the perf machine for you to gain more insight. The usual things, like perf-marks, are in telemetry but are there chrome/electron perf recorders that I should run? While the general trend is maybe positive there is a class of (old?) machines where performance is horrible. It would be awesome if we can figure what those characteristics are so that we can guestimate how many stable users will be affected. |
|
Results from my Windows Desktop: |
|
closing this as a dupe of #101083 |
Following results are from running https://github.com/microsoft/vscode-build-tools/blob/master/perf/perf-canary.ps1 unmodified
Summary: BEST
842ms, VERSION288852d8c26d797974bfb8aed06e1bff9b809223, APPCode - Insiders.exeSummary: BEST
875ms, VERSION6c8ce010748453b34189d61a636c57e79f2f53a8, APPCode - Exploration.exeThe text was updated successfully, but these errors were encountered: