Slow startup time on 1.82.0 #192493
Comments
bpasero
added
the
freeze-slow-crash-leak
|
Thanks for providing very good context 👏 Some ideas: does it reproduce when you run |
bpasero
added
info-needed
|
Same issue with version 1.82 on Debian 12. |
Yes, it reproduces : I also noted that the two steps |
|
Can you try to reproduce with our nightly insider builds? You can give our preview releases a try from: https://code.visualstudio.com/insiders/ |
|
I have the same problem with an insider build : |
|
How about |
|
Same results : |
|
GIven most of the slowdown is in @x-hgg-x can you perform the following steps to help us get a runtime trace,
|
|
Here is the trace : Curiously the performance marks have now changed : Show
|
|
Can you do another run to see if the performance marks have consistently changed. |
|
Results on successive launchs using 1st launch with an empty `data` folder
2nd launch
3rd launch
4th launch
5th launch
6th launch
|
|
Using Result 1 (50% of time)
Result 2 (50% of time)
|
|
Here is the trace corresponding to the 2nd launch : Associated performance marks
|
|
Here is the trace corresponding to the 1st launch, with an empty Associated performance marks
Note: there aren't any slowdown here in the |
|
Seems like you have specified |
|
Here is the trace without Associated performance marks (no slowdown in the
|
| What | Duration | Process | Info |
|---|---|---|---|
| start => app.isReady | 2711 | [main] | initial startup: true |
| nls:start => nls:end | 0 | [main] | initial startup: true |
| require(main.bundle.js) | 55 | [main] | initial startup: true |
| start crash reporter | 0 | [main] | initial startup: true |
| serve main IPC handle | 1 | [main] | initial startup: true |
| create window | 28 | [main] | initial startup: true, state: 0ms, widget: 28ms, show: 0ms |
| app.isReady => window.loadUrl() | 105 | [main] | initial startup: true |
| window.loadUrl() => begin to require(workbench.desktop.main.js) | 43 | [main->renderer] | NewWindow |
| require(workbench.desktop.main.js) | 322 | [renderer] | cached data: NO, node_modules took 0ms |
| wait for window config | 1 | [renderer] | - |
| init storage (global & workspace) | 72 | [renderer] | - |
| init workspace service | 73 | [renderer] | - |
| register extensions & spawn extension host | 251 | [renderer] | - |
| restore viewlet | 0 | [renderer] | - |
| restore panel | 0 | [renderer] | - |
| restore & resolve visible editors | 2 | [renderer] | 0: |
| overall workbench load | 89 | [renderer] | - |
| workbench ready | 3349 | [main->renderer] | - |
| renderer ready | 492 | [renderer] | - |
| shared process connection ready | 198 | [renderer->sharedprocess] | - |
| extensions registered | 3685 | [renderer] | - |
|
I think since activating the trace mode slows down VS Code, this leaves more time for the renderer to initialize, so we don't see the slowdown in the |
|
I can reproduce part of the issue on another machine running on Ubuntu 20.04, where I observe that |
|
Thanks for the traces, there are two points of interest from the runtime trace and the application profile.
|
|
@x-hgg-x can you provide the following additional data,
|
|
I don't see any slowdown from the trace, the time navigation started in the main process till the renderer finished loading and started script execution is only 225ms Main Process: Render process: |
|
Yes, when launching with a trace, the startup performance doesn't show any slowdown, since VS Code already takes 3s to launch: Performance Marks with the trace
|
|
Here is the same trace, but from VS Code 1.81.1, where I don't have the issue: Performance Marks with the trace for VS Code 1.81.1
|
|
Here is the profile and trace from the last insiders version, generated from the command There is a big slowdown in the In this case the Performance Marks with the trace
|
|
Thanks for the perf marks, there are two issues in your case.
Both cases the work is done by the runtime, also it is interesting that 1) has an impact on the timings for 2). Investigating 2) with the current traces is useless as the timings are skewed. I am unable to repro 1) on my device, so seems specific to your setup. I will provide commands to collect |
|
Having similar symptoms on Arch with version 1.82 (VSCodium). Slow startup has become very noticeable. |
|
@jurisevo slow startup can be for different reasons, please open a separate issue with relevant data following the steps at https://github.com/microsoft/vscode/wiki/Performance-Issues |
|
Whilst I've not noticed issues with startup time, 1.82.something was kicking my CPU into overdrive whilst in use (simple script editing, nothing else). I could close VS Code and the CPU fan would spin down seconds later, and repeat this issue. Upgraded to 1.83 minutes ago and all is quiet so far. |
|
code-1.83.1-1696982959.el7.x86_64 on RHEL8 with a few extensions and startup time is > 10s |
|
@ElCoyote27 FWIW, 1.84.1 is GA now. |
|
I have still the problem on 1.84.1. |
|
same on 1.84.2 |
|
I seem to be experiencing this issue, with |
|
Still experiencing this issue on 1.85 on Fedora 39 and can confirm that the problem goes away when downgrading to 1.81. |
|
As far as I can tell, I'm experiencing this issue on VS Code 1.86 (Insiders as well) on Debian 12 with Intel graphics. |
|
To everyone else, try this: (The launcher will complain about an unknown option, that's normal.) |
|
@whitequark yes, this did improve startup. And yes, I also experience issues on a computer with Intel graphics: Mesa Intel® UHD Graphics. What are some other implications of using these options, no GPU rendering I suppose?
|
I have no idea honestly. VS Code still launches a GPU process and it's still doing something. It seems like not passing |
No need, thank you for your response! I'm OK with patching the launcher command on this one computer that exhibits the issue. |
|
Can you share the patch? I made a shell alias but it seems to affect the launcher's behavior in some odd way. |
Well, patch is a strong word, I just changed the |
|
You can also update |
|
Have you tried that? It seems to ignore |
Unfortunately it also doesn't work for me, since apparently only a subset of the arguments are allowed : https://github.com/microsoft/vscode/blob/1.86.1/src/vs/workbench/electron-sandbox/desktop.contribution.ts#L344 |
With all extensions disabled, VS Code 1.82.0 takes 4x more time to start than VS Code 1.81.1, due to a slow renderer :
1.81.1
System Info
Performance Marks
Raw Perf Marks: renderer
1.82.0
System Info
Performance Marks
Raw Perf Marks: renderer
Detailed profiles :
profile 1.81.1.tar.gz
profile 1.82.0.tar.gz
OS : Linux Mint 21.2 Victoria
The text was updated successfully, but these errors were encountered: