[perf] UI stalls and freezes when searching single whitespace

[jrieken]

• vscode repo
• open search vielwet
• expand replace part of the widget
• search for a single space
• in the file-include box type out **/electron-browser/**/*.test.ts
• 🐌 notice how everything becomes sluggish

The performance trace shows some really long tasks that are preceded by some also long work

Profile-20230116T172636.json.zip

[andreamah]

Hmm, I'm not sure if I can replicate it; do you have windows defender enabled to scan the vscode folder?

[roblourens]

I also can't repro an issue. But do you know what it means to have a long task with no code under it?

[jrieken]

No, unsure what that means. Usually, it's the browser that is doing stuff. I don't reproduce today, maybe there was fluke or some unwanted accessibility mode (@deepak1556 do we still have the problem?)

Tho, just before the l o n g task there is some actual work for ~500ms in JS. Maybe that's a hint?

[jrieken]

⬆️ That's what I mean (wrt long JS). It takes around 300-500ms on my machine (which is a really fast machine)

[deepak1556]

some unwanted accessibility mode (@deepak1556 do we still have the problem?)

Nope its addressed in Insiders since f807491

[andreamah]

No, unsure what that means. Usually, it's the browser that is doing stuff. I don't reproduce today, maybe there was fluke or some unwanted accessibility mode (@deepak1556 do we still have the problem?)

Tho, just before the l o n g task there is some actual work for ~500ms in JS. Maybe that's a hint?

One thing I notice is that it's refreshing the tree quite a bit. Could you try to perform the trace in OSS so that I have a better idea of what is calling it?

[lramos15]

My editor locks up all the time searching causing the entire UI to become unresponsive. This is not only on white space search, but on all searches. I even have what I consider to be fairly conservative inclusions and exclusions. I include *.ts and exclude build/ and extensions/ so I'm only looking at VS Code source code.

I got a few CPU profiles.

The .json is from OSS and the .cpuprofile is from current insiders.
Profile.zip

@jrieken helped me do some digging through these profiles and it appears https://github.com/microsoft/vscode-distro/blob/e89a0ccea11902c6f67324fd38cd613f9bd90c5d/src/vs/workbench/contrib/search/browser/searchView.ts#L495-L498 might be the culprit. My search is unusable when the replace widget is visible, but when it is not everything is much smoother.

[jrieken]

I think the culprit is that setReplaceAllActionState is called repeatedly (at least twice). You can see that from the attached profile and also when debugging. That in return triggers a full tree refresh which I believe is responsible for the freeze.

This gist (and repro steps) is that this requires the replace-part of the widget to be visible (I have updated the steps accordingly)

[andreamah]

@lramos15 when you were taking the perf log, how many searches did you do? Was it locked up the entire time that the perf logger was running?

[andreamah]

Also, in the profile, I saw many instances of onSearchInputChanged. What exactly was happening during the profile? Were you typing in the input box at all?

[jrieken]

@andreamah Can you not reproduce this locally?

[lramos15]

@lramos15 when you were taking the perf log, how many searches did you do? Was it locked up the entire time that the perf logger was running?

I would say a small handful. It doesn't seem to matter though, when I start typing it locks up or when I go to change the query it locks up. Maybe this has to do with refreshing while the tree is populating, I'm unsure.

[andreamah]

@andreamah Can you not reproduce this locally?

I can't repro this locally, but I'm trying to look into the logs. I think it's about this call here:

vscode/src/vs/workbench/contrib/search/browser/searchWidget.ts

Line 482 in 8b76efe

this._onReplaceStateChange.fire(newState);

sometimes being unnecessary, but I'll need to think a bit about a clean fix for this.

[andreamah]

@lramos15 @jrieken If you're not seeing this anymore, can we close this? (and re-open if the behavior appears again)

[lramos15]

Yes feel free to close and I will try to verify it for endgame