VSCode 1.66 slow, laggy when re-focusing/switching back to editing from another window or program

[lorand-horvath]

Does this issue occur when all extensions are disabled?: Yes

• VS Code Version: 1.66.0
• OS Version: Windows 7 SP1 x64

Steps to Reproduce:

1. Open any JS file and then switch window/focus to another app (e.g. a browser)
2. Switch/focus back to VSCode JS file and it takes about 2 seconds to be able to edit. It's some kind of lag, it takes time until you can start editing again.

[lorand-horvath]

Also this popup appears when I try to close VSCode, it stays on for 20-30 seconds. This has never occurred with 1.65.x or older versions.

[lorand-horvath]

@sandy081 @deepak1556 Latest VSCode 1.66.0 is getting ridiculously slow after a while, there must be some kind of memory leak happening. It's unresponsive for a few seconds when I click back into the editor from another program.

Is there anything to be done? How can I help? I don't really want to revert to the previous version 1.65.2, which did not exhibit any slowness - it was working fine.
Note: nothing changed in my setup since 1.65.2, only VSCode was updated to 1.66.0.

[deepak1556]

Can you start the application with --disable-features=CalculateNativeWinOcclusion commandline flag and check if the issue repros. It is very likely the process is put into a suspended state due to the occlusion tracker from the runtime.

[lorand-horvath]

@deepak1556 Will do. In the meantime, I've checked the Performance tab in vscode devtools and I think I've found the task that takes 2+ seconds when I re-focus in the main vscode editor window.
It's called xterm-addon-webgl.js https://www.npmjs.com/package/xterm-addon-webgl

[lorand-horvath]

@deepak1556 I've tested with > code --disable-features=CalculateNativeWinOcclusion
It seems to be quite faster to re-focus from another program, so that seems to do the trick. But I've also noticed it is very slow to open a file if I right click in Windows Explorer on a file and Open with VScode - it takes about 3-4 seconds to open it in VSCode.

Why is the CalculateNativeWinOcclusion feature slowing things down when re-focusing? What can be done to fix the slowness?

Edit: With the CalculateNativeWinOcclusion feature disabled, VSCode can also be closed very fast (almost instantly), same as it always was in previous versions, that popup Closing the window is taking a bit longer... doesn't appear anymore.

Edit2: The Chromium project added the native window occlusion calculation "feature", which seems to be causing this issue between v91 (VSCode 1.65.2) and v98 (VSCode 1.66.0) https://blog.chromium.org/2021/12/chrome-windows-performance-improvements-native-window-occlusion.html

[lorand-horvath]

Can we please add this issue to March 2022 Recovery (1.66.1) milestone?

[deepak1556]

Merging to #123257

[lorand-horvath]

@deepak1556 I think the issues reported in the merged ticket #123257 are not the same problems that I reported here, because the slugish behavior only started with VSCode 1.66 and I haven't noticed any of that in previous versions.

Can we keep this issue open independently from #123257 please? At least until the problem is tracked down properly.
Or I might have to revert to 1.65.2 in order to be able to work on my projects at all.

[xPaw]

I'm seeing the same problem on 1.66 which is new. Another thing that happens is while Code is starting, it first looks like a Windows 7 titlebar (I am on Windows 10) until it finally loads, as well as the "closing the window is taking a bit longer".

Neither of these issues happened before.

[deepak1556]

titlebar issue is captured in #146683, please follow that issue for updates.

[lorand-horvath]

@deepak1556 Do you think the bump to Electron 17.4.0 10ab34d will help? Some bugs related to window/focus/bounds have been fixed... https://github.com/electron/electron/releases/tag/v17.4.0

[deepak1556]

Nope they are unrelated, occlusion tracking for windows is performed by https://source.chromium.org/chromium/chromium/src/+/main:ui/aura/native_window_occlusion_tracker_win.cc and there have been some changes between Chromium 91 and Chromium 98 which would have caused this regression.

Can you share a screen capture of the exact steps that show the issue, it would help me to repro the issue on my end. Also, are you running VSCode in a virtual desktop environment ?

[lorand-horvath]

@deepak1556 It would be difficult to show the issue with a screen capture. It's actually very simple: click away from VSCode into another window, e.g. the Chrome browser and then click back from Chrome into VSCode on a particular workspace tab and it takes about 2-3 seconds for it to become active and to be able to edit anything.
Also, when I close the main VSCode window, a Closing the window is taking a bit longer... message appears as I mentioned #146737 (comment) and @xPaw confirmed #146737 (comment)

I'm not running VSCode in a virtual desktop environment. It's just a dual monitor Win 7 x64 setup, nothing fancy.

I have just tried with the updated version 1.66.1, it still has the same laggy behavior. I've noticed it's still using Electron 17.2 which is known to be buggy. You bumped it up to 17.4 yesterday 10ab34d - wondering why is it not included in the latest release? Will it at least be included in the April 1.67 release?

So I might just have to revert to 1.65.2 until May... it worked fine and didn't exhibit slowness like the 1.66 series.

[lorand-horvath]

@deepak1556 Is there anything to be done about this other problem, which seems to be somewhat related to the lag issues? Namely, when closing VSCode, it takes about 20 seconds with this spinner waiting for something:

[deepak1556]

/cc @bpasero for the above dialog

@lorand-horvath can you check if the dialog appears with https://code.visualstudio.com/insiders ?

[bpasero]

The two main components that contribute to this dialog have either moved out of the window into the majn process (storage), or now store periodically (timeline history), so I would expect insiders to improve this situation.

Besides, in insiders you now see the name of the component that slows down shutdown.

[lorand-horvath]

@deepak1556 @bpasero I've just tested 1.67 and sorry to say, the lag and slowness when switching from Chrome to a VSCode tab is exactly the same as in 1.66+. Last version without this issue is 1.65.2.

Just checked 1.67 comes with Electron 17.4.1, but there are newer versions 17.4.2 and even 17.4.3.... wonder if it could be updated?

[lorand-horvath]

Electron 17.4.2 https://github.com/electron/electron/releases/tag/v17.4.2
Electron 17.4.3 https://github.com/electron/electron/releases/tag/v17.4.3

[vhscom]

Also this popup appears when I try to close VSCode, it stays on for 20-30 seconds.

Started seeing this pop-up over the last few weeks time-to-time on a 2019 MBP. When I bumped up to the April 2022 release I started seeing it consistently when closing windows. And I'm also getting about a 10 second lag between code changes and visual feedback in TypeScript on the same machine running the April (and March, after I tried a rollback) releases.

[isidorn]

Thanks for filling this issue, but it seems to be reported for Win7 which we do not support https://code.visualstudio.com/docs/supporting/requirements#_platforms

Can you reproduce with Win11 or Win10?
Thanks!

[lorand-horvath]

@isidorn Ouch, it seems you've silently dropped support for Win 7 between February and April, at least according to web.archive

I will try Windows 10 maybe next year... but for now I'll stay on Win 7 (I despise Win 10 with a passion) and revert to VSCode 1.65.2. Thanks for the heads up!

[j3mdamas]

I experience it on Ubuntu, through snap install.

[lorand-horvath]

I experience it on Ubuntu, through snap install.

@j3mdamas That's interesting, so the thing to blame here might not be the Win 7 OS being unsupported all of a sudden (though I had a feeling it doesn't have anything to do with it).
Give us more details, please.

[icedterminal]

@lorand-horvath I'm not sure why Windows 7 was even brought up. Doubtful of the relevance of this statement. This is quite perplexing to me. If you think about, I wouldn't be in this thread if I weren't having the issues already outlined. I use Windows 10. Gave an example video showing how much slower the current release got on launch. That is 100% reproducible. The pop up saying it's taking longer to close and the lagging is sporadic in nature and not 100% reproducible. It can happen within 10 minutes of being open or it can take several hours. When you pointed out a specific version to use, I reverted and have yet to experience what's been outlined.

I'll have to upgrade to the current release and keep a replay buffer going recording my working sessions.

[lorand-horvath]

@icedterminal I agree with what you're saying/observing. Windows 7 has nothing to do with this issue. It can be convenient to sweep the issue under the "Windows 7 is not supported anymore" rug, now that support has been silently and suddenly dropped for it (some time since VSCode 1.66, around April 2022).

Since upgrading to 1.67 I don't get the "Closing the window is taking a bit longer" popup anymore, which is good. But the 2 second lag & slowness to respond when re-focusing from another program onto a VSCode tab is still there and it's honestly starting to drive me nuts. Anybody can imagine testing your bundled JS code in Chrome and when you click back to VSCode to edit your code, well... you have to wait 2 seconds for it to become responsive. Every. Single. Time. It's ridiculous!

Note 1: Starting VSCode with code --disable-features=CalculateNativeWinOcclusion doesn't help at all anymore. It only worked in 1.66 which used Electron 17.2. Since VSCode 1.67 with Electron 17.4 it just doesn't make any difference whether you add the flag or not.

Note 2: Is there any way for me to reopen this issue? It has been closed by @deepak1556 and now I can't open it anymore, even if I was the one reporting it in the first place. Please don't tell me to open another issue.... that's just not a productive way of tracking down and fixing bugs.

[lorand-horvath]

I will merge this to #123257 for the occlusion tracker related regressions, although the issue here started with Electron 17 update, we will have more of these regressions as long as the renderer throttling is aggressive. I will see if we can make it less aggressive for the desktop application.

@deepak1556 Can you please reopen this issue, since it's not caused by the native occlusion tracker, it seems. Please read my comment right above this one. Is there anything to be done about this problem, which, as you can see, occurs also under Windows 10 and Ubuntu as mentioned above? Can we try Electron 16 or 18 or even roll back to 13.5.2 which didn't have any noticeable lag up to VSCode 1.65.2?

[deepak1556]

@icedterminal please open a separate issue for the slow startup issue and provide the numbers following the steps at https://github.com/microsoft/vscode/wiki/Performance-Issues#read-the-startup-timers. This issue was originally opened for unresponsiveness when focusing VSCode from another application which is different from the issue you are describing.

@lorand-horvath as mentioned in #146737 (comment) if you can repro the issue on newer windows then we can reopen the issue to further investigate it with ETW profiles. Windows 7 is not officially supported by Nodejs or Electron, so there could be other system calls added in newer versions that could cause the slowdown in your case, occlusion tracker was just one element to the cause to be tested.

[icedterminal]

@deepak1556 Thanks for the response

This issue was originally opened for unresponsiveness when focusing VSCode from another application

I realise that. Nuking %AppData%\Code which had ballooned to 300mib solved the slow down on launch with v1.66 and later, where as it didn't matter with 1.65 and earlier.

That said I still do experience the lag between application focusing (Alt + Tab) and taking longer to close. It's just so random and inconsistent. I have installed 1.67 and will use a replay buffer to catch it when and if it happens.

[lorand-horvath]

Nuking %AppData%\Code which had ballooned to 300mib solved the slow down on launch with v1.66 and later, where as it didn't matter with 1.65 and earlier.

@icedterminal Good point! I'll uninstall VSCode completely and nuke the %AppData%/Code as well - it's 360 MB in my case... lots and lots of cached files in there AFAICS. Then will do a clean install of 1.67.2 when it comes out, hopefully today.

[skaldesh]

I am on Arch Linux with Sway WM:

Version: 1.67.2
Commit: c3511e6c69bb39013c4a4b7b9566ec1ca73fc4d5
Date: 2022-05-20T07:44:59.452Z
Electron: 17.4.3
Chromium: 98.0.4758.141
Node.js: 16.13.0
V8: 9.8.177.13-electron.0
OS: Linux x64 5.15.43-1-lts

I can confirm the bug there as well, that after switching focus from another application back to VSCode, it takes between 1-3s until VSCode becomes responsive again. I am happy to help debug, if need be.

[lorand-horvath]

@deepak1556 As you can see, this issue happens on Linux and Windows 10 as well, so blaming it on Windows 7 is not a solution.
Can you please look into this problem? It is really annoying and can't focus on my work properly when trying to use this editor.

I'd like to ask you, if possible, to create an insiders build with Electron 18 or 19 so we can test. I bet the problem is caused by Electron 17 specifically, because it only appeared since Electron 17 has been in use.
I would also like to mention that disabling the native occlusion tracker doesn't help at all anymore. It only seemed to help somewhat in VSCode 1.66 (Electron 17.2), but I see absolutely no improvement in lag behavior since VSCode 1.67 (Electron 17.4).
This is why I assume it's Electron 17 that is responsible for the lag.

[isidorn]

@skaldesh thanks for commenting. Can you please open a new issue following steps from https://github.com/microsoft/vscode/wiki/Performance-Issues#read-the-startup-timers
Feel free to ping me on the new issue @isidorn and then we can take it from there. Thanks a lot!

[lorand-horvath]

@isidorn Thanks for your comment, but this is not about the startup lag. I see several comments from you and other developers asking for the startup performance assessment, but we have to first realize that what I reported here is about focusing back to VSCode from another program, after VSCode has been started. It has nothing to do with any startup lag or startup-related issues.

[skaldesh]

@lorand-horvath is right, the startup of VSCode is fast. Refocusing to an already started instance is what causes the freezes

[isidorn]

@lorand-horvath you are correct, this might not be about startup lag. So @skaldesh when filling a new issue you do not have to strictly follow those steps, just provide as much detail as possible. Thank you

As for the Electron 18 and 19 build, this is something which we have on the plan in the future. This will be reflected on our iteration plan. As soon as we have something you should be able to try it out. Thanks!

[skaldesh]

Will do :) Thanks

[lorand-horvath]

As for the Electron 18 and 19 build, this is something which we have on the plan in the future. This will be reflected on our iteration plan. As soon as we have something you should be able to try it out. Thanks!

@isidorn Thanks for this information, I'm definitely looking forward to testing a VSCode build based on Electron 18+

@deepak1556 I've just read your comment regarding the update to Electron 18 #145527 (comment) which I'll keep an eye on.

[lorand-horvath]

How can I reopen this issue? If I create another one, it will be closed since it would be considered a duplicate. Catch 22?

[lorand-horvath]

@deepak1556 @isidorn I have good news - I have finally managed to solve this problem on Windows 7 x64.

The solution to get rid of the slowness and get back the snappiness and quick reaction when focusing back to VSCode from another program is to uninstall VSCode, restart the PC and completely remove the folder C:\Users\[User]\AppData\Roaming\Code, which in my case had 380 MB and several thousand files cached in it. The folder has grown so much over 2 years of daily VSCode use, with regular upgrading to newest version as soon as it was released. I've also removed the VSCode extensions folder C:\Users\[User]\.vscode, I'm not sure whether that helped or not.

After reinstalling VSCode I had to reconfigure everything from scratch and install all extensions, but the cache folder is now only 80 MB and contains 550 files. Working with VSCode is a breeze again...

*Credit goes to @icedterminal #146737 (comment) - thanks for the idea!

*Cross-referencing possibly related issues, perhaps it helps someone else not noticing this solution: #123257 #141735 #147151 #147188

Edit: Slow file open fixed as well - brilliant!

[ghost]

@lorand-horvath I don't see that as a solution - at most a temporary one.
Deleting, reinstalling and reconfiguring everything can't be in the inventor's spirit and what about it in a few months? This happens again?