VS Code starts slowly when the Settings editor is open

[Rigel-Developer]

1. ⚠️ We have copied additional data to your clipboard. Make sure to paste here. ⚠️
2. ⚠️ Make sure to attach these files from your home-directory: ⚠️
   -prof-QZ5MV1W0.main.cpuprofile.txt
   -prof-QZ5MV1W0.renderer.cpuprofile.txt
   prof-QZ5MV1W0.main.cpuprofile.txt
   prof-QZ5MV1W0.renderer.cpuprofile.txt

[jrieken]

@Rigel-Developer What version of VS Code is this?

[jrieken]

@Rigel-Developer Does this happen when starting/reload with no editor open, a text file open, or the settings editor open?

[jrieken]

Without version info it's hard to pin-point the issue but there is some listener that is doing too much while/after scanning extensions and updating the configuration model. My qualified guess is that this is the settings editors. When running out of source it shows really terrible performance (freezing the renderer for ~500ms on my very fast machine) and the "shape of the traces" look very similar

[Rigel-Developer]

@Rigel-Developer What version of VS Code is this?

Versión: 1.77.1 (user setup)
Commit: b7886d7
Fecha: 2023-04-04T23:21:11.906Z
Electrón: 19.1.11
Chromium: 102.0.5005.196
Node.js: 16.14.2
V8: 10.2.154.26-electron.0
OS: Windows_NT x64 10.0.22621
En espacio aislado: No

[Rigel-Developer]

@Rigel-Developer Does this happen when starting/reload with no editor open, a text file open, or the settings editor open?

Every time I open the application it is very slow new project or loading one is always slow

[rzhao271]

\gifPlease

[vscodenpa]

Thanks for reporting this issue! Unfortunately, it's hard for us to understand what issue you're seeing. Please help us out by providing a screen recording showing exactly what isn't working as expected. While we can work with most standard formats, .gif files are preferred as they are displayed inline on GitHub. You may find https://gifcap.dev helpful as a browser-based gif recording tool.

If the issue depends on keyboard input, you can help us by enabling screencast mode for the recording (Developer: Toggle Screencast Mode in the command palette). Lastly, please attach this file via the GitHub web interface as emailed responses will strip files out from the issue.

Happy coding!

[jrieken]

@rzhao271 With these steps I can reproduce the freeze

• open settings editor
• reload window
• there is very slow handling of the onDidChangeRestrictedSettings event via this callback

This aligns with my (out of dev) profiling and the attached CPU profile. Check minified source code of the 1.77.1 release and the Hc function on line 2311

[Rigel-Developer]

Recently when I open vscode I always get this message, if I click the button to reopen vscode it closes and does not open again

[rzhao271]

\closedWith 600b519

[jrieken]

I do see an improvement 🥳 but not a big one, using a temporary profile I see a speed up from 60ms to 30ms but with my real world profile (that I selfhost on) I see times of 120+ms for opening the settings editor. My setup is very average wrt the number of extensions (and therefore settings) that I have installed. Given my machine's performance is far above average I'd it fair to assume real world opening times of 500ms to 1sec.

@rzhao271 Profile shows that most time is spend in inspect of all configurations. Why is that needed upfront? @sandy081 Why is it so slow and can this be used different? We do manage the get the whole configuration data over to the extension host without any noticeable performance impact so I wonder why this is so different

[sandy081]

Why is it so slow and can this be used different? We do manage the get the whole configuration data over to the extension host without any noticeable performance impact so I wonder why this is so different

Inspect is more than just sending whole configuration data. A key can have different values at different targets/overrides and inspect gives you all these values.

export interface IConfigurationValue<T> {

	readonly defaultValue?: T;
	readonly applicationValue?: T;
	readonly userValue?: T;
	readonly userLocalValue?: T;
	readonly userRemoteValue?: T;
	readonly workspaceValue?: T;
	readonly workspaceFolderValue?: T;
	readonly memoryValue?: T;
	readonly policyValue?: T;
	readonly value?: T;

	readonly default?: { value?: T; override?: T };
	readonly application?: { value?: T; override?: T };
	readonly user?: { value?: T; override?: T };
	readonly userLocal?: { value?: T; override?: T };
	readonly userRemote?: { value?: T; override?: T };
	readonly workspace?: { value?: T; override?: T };
	readonly workspaceFolder?: { value?: T; override?: T };
	readonly memory?: { value?: T; override?: T };
	readonly policy?: { value?: T };

	readonly overrideIdentifiers?: string[];
}

All these values have to be frozen so that the caller wont mess up with the source. It is already smart to freeze them only when asked for the specific target. At present effective value is always computed when asked to inspect. May be I could also make it on demand.

@rzhao271 Can you please let me know how you are using inspect and what accessor of inspect result is taking time?

[sandy081]

@rzhao271 One observation is that opening a settings editor is calling the inspect method ~1600 times. I am assuming we are calling inspect for every setting even if it is not rendered. One good low hanging improvement we can do here is reducing the number of inspect calls - inspect only when a setting is visible/rendered. We show a max of 15-20 settings and if we can avoid calls for other settings, we would gain more than 95%.

[rzhao271]

#190100 adds in a change that calls inspect more lazily. @jrieken let me know if you notice an improvement or have any concerns.

One remaining area of potential improvement I know of would be to use settingsTree.rerender() or settingsTree.setChildren() with diffIdentityProvider to rerender the setting tree more efficiently, but I have not looked into it yet.

Before

After

[sandy081]

@rzhao271 Thanks for doing the change

[jrieken]

👏 Nice, so much better now

[rzhao271]

Closing this issue for verification.