[Bug]: Performance regression in 24.x #37454
Comments
|
@Prinzhorn Sorry, just want to verify - I took a look at the gist, is the specific measurement here for time to start/time to load webContents? Just wanted to make sure we're looking at the right thing as we debug 👀 Thanks for reporting this! |
|
I chose this event seemingly at random. What I noticed was that it took longer than expected to launch a Fiddle with 24.x and this was the first event I tried to make this measurable. So no, unfortunately I cannot narrow it down any further. It's just what I felt, I think opening the window is as fast as usual but then the window is blank for longer than with 23.x. That's what I originally noticed (content showing slower than with 23) |
|
Here's a slightly updated Fiddle. I won't go any further to avoid duplicate work. And frankly I don't know what other events could be used best to narrow this down further. But it appears it's actually the loading itself. https://gist.github.com/7fb4af51631340ef4bb2f21033c977c0 |
|
I don't see this on macOS: So I guess this is Linux-specific..? |
I could not reproduce in a Windows VM either. Out of curiosity I added one more metric: https://gist.github.com/ac076574ef7e619cc7a1c304a4f9b031 Not sure this helps, because it makes it look like things are "just slow"? Because the requests takes longer to arrive but then it also takes longer to finish loading. |
|
Can you also try measuring the time from app boot until did-finish-load? I wonder if some other initialization got moved around and you're now measuring that too, when you weren't previously. |
|
Like this? It appears that v24 is slower in general, it's not just the slice I'm measuring (not WebContents related at all). Are there like debug symbols in the v24 Linux build or anything along those lines that make this slow in general? const { app, protocol, BrowserWindow } = require('electron')
const path = require('path')
function createWindow () {
// Create the browser window.
const mainWindow = new BrowserWindow({
width: 800,
height: 600,
webPreferences: {
preload: path.join(__dirname, 'preload.js')
}
})
protocol.registerFileProtocol('atom', (request, callback) => {
console.timeEnd('got-request');
callback(path.join(__dirname, 'index.html'));
})
console.time('did-start-loading');
console.time('did-finish-load');
console.time('got-request');
mainWindow.webContents.on('did-start-loading', () => {
console.timeEnd('did-start-loading');
});
mainWindow.webContents.on('did-finish-load', () => {
console.timeEnd('did-finish-load');
app.quit();
});
// and load the index.html of the app.
mainWindow.loadURL('atom://');
}
app.whenReady().then(() => {
createWindow()
})If I It might be worth noting that v24 spits out |
|
If I look at the following it might be related to the window? I'll look into that. const { app } = require('electron')
app.quit();Edit: unfortunately I'm not well and can't look into this any further now. |
|
|
|
I wonder why this does not block stable? The time it takes for |
|
I have been experiencing an issue that might be similar, but not limited to v24 it seems to have originated back in v13
I have a intel integrated gpu and a discrete nvidia gpu that was recently disabled prompting me to start seeing this issue. I have also checked the most recent version of chromium available to my machine at this time Maybe this info will help you pin down when/where yours occurs. |
|
I just did some triage on 37736, which as @Prinzhorn has pointed out is probably a duplicate of this ticket. If this is the same as 37736, it was introduced in v24.0.0-nightly.20230202...v24.0.0-nightly.20230203 which happily only has two commits between them:
|
|
|
FYI... some more context. Looking at 25.0.0 nightlies, it looks like the issue was fixed in v25.0.0-nightly.20230322 So it looks like this chromium roll fixed the issue: |
|
Looks like it is a V8 issue. This CL appears to have fixed the issue in the nightlies: https://chromium-review.googlesource.com/c/chromium/src/+/4355892. I'll try to isolate it down to figure out which V8 commit fixes the issue: https://chromium.googlesource.com/v8/v8/+log/596d10a8..90ff6c03 |
|
Ok... pretty sure I found the cause and fix.
I'm testing a cherry-pick to 24 and will update once I can test it. |
|
Ok - I just tested it. https://chromium-review.googlesource.com/c/v8/v8/+/4338176 fixes the issue. I'm going to throw the fix into the 24 chromium roll here: #37767. |
|
Legend |
* chore: bump chromium in DEPS to 112.0.5615.49 * fix: Store the thread stack start in TLS. https://chromium-review.googlesource.com/c/v8/v8/+/4338176 Fixes #37454 --------- Co-authored-by: electron-roller[bot] <84116207+electron-roller[bot]@users.noreply.github.com> Co-authored-by: John Kleinschmidt <jkleinsc@electronjs.org>
Preflight Checklist
Electron Version
24.0.0-alpha.6
What operating system are you using?
Ubuntu
Operating System Version
Linux alex-NUC11PAHi7 5.19.0-31-generic #32-Ubuntu SMP PREEMPT_DYNAMIC Fri Jan 20 15:20:08 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
What arch are you using?
x64
Last Known Working Electron version
23.1.1
Expected Behavior
24 as fast as 23
Actual Behavior
Slower
Testcase Gist URL
https://gist.github.com/419cb8aed0be96a28afa3077be0db4ee
Additional Information
I just did some entirely unrelated debugging in Fiddle and found a noticeable delay when using 24.
In the Fiddle I'm consistently getting ~70ms (50 to 80) for 23.1.1 and ~200ms (180 to 210) for any 24 alpha (1 through 6).
For anything more complex it is way more noticeable, but the hello world Fiddle is enough as PoC.
The text was updated successfully, but these errors were encountered: