Discussion: Is it me or Visual Studio Code performance degrades over time in the span of a few hours?

[tommai78101]

Version: Visual Studio Code Stable v1.23.1
OS: Windows 7 Enterprise LTS

This is a discussion. I cannot ask this on Stack Overflow, and there really isn't any community forums I can participate in that has an active developer-oriented userbase with 100% guaranteed Visual Studio Code users. All other communities are not 100% guaranteed.

This is mainly targeted at Visual Studio Code users who kept the application running for more than a few hours.

I would like to ask if anyone has experienced performance degrading / slowdowns when using Visual Studio Code for long periods of time, in a span of a few hours ranging from 2 hours to 5 hours?

Slowdowns include:

• There is significant delay observed when the text cursor is responding to arrow keys on the keyboard.
  • More apparent is when you hold down the Left or Right Arrow keys, the text cursor jumps a couple of characters, instead of traversing through each character/letter in a word or a line of code.
• When navigating code using Page Up or Page Down keys, there are times when code syntax highlighting would color all of the visible codes as 1 solid color, and it takes a while for the application to syntax-colorize the codes properly.
• When attempting to open new documents in the Explorer pane on the side, the process of opening a document varies greatly depending on the size of the contents of codes. When cold-booting Visual Studio Code, the documents are opened immediately without noticeable delays.
• With ESLint installed, attempting to parse JavaScript files causes Visual Studio Code's performance to degrade faster. I'm thinking it's because it's constantly parsing for syntax errors and issues whenever a Save operation occurs.
  • With no extensions enabled, the performance degrading still occurs, but it's very gradual and slow.
• I do not see observable memory leaks.
  • Even if I don't see it, there would be quite a lot of Github Issues reporting on said leaks, if it did occur.

Let me know if what I'm experiencing is actually happening with Visual Studio Code, or it's because I'm running on a workstation and it's something else on my workstation that's memory hogging up resources for Visual Studio Code.

I just wanted to see more anecdotes than myself.

Thanks for reading.

[rgosens2]

Electron...probably leaking memory like a sieve.

[foxbunny]

On Windows 10, I've noticed the same slowdown with no noticeable memory leak (Code stabilized at around 1.5GB RAM). I haven't really measured how much time it takes, but it's around long enough to forget when I started. It also doesn't help that it becomes gradually more sluggish over time so it's hard to pinpoint the exact time when it happens. Symptoms are exactly as in the original post.

I've experienced this on Windows 10 on two separate machines, one a dual-core i7 with 12GB RAM and another a quad-core i7 7700HQ with 16GB RAM. Both with TypeScript and plain JavaScript with jsconfig. On the first machine, I also tried Linux for a while (Ubuntu), and I did not experience slowdowns of any kind.

[tomzx]

@tommai78101 Can you use the "Help - Report Issue" feature of VS Code to let us know what your system information, and more specifically, your installed extensions are?

Thanks!

[svipas]

I noticed if I open project for a long time sometimes autocomplete disappears and I need to reload window to get autocomplete back. Overall it looks good. Also, I believe after updating Electron to 2 version performance will be increased since it will get newer Node.js and Chrome version as well as other benefits.

[tommai78101]

@tomzx Sure

System Specs

CPUs	Intel(R) Xeon(R) CPU E5-1603 v3 @ 2.80GHz (4 x 2793)
GPU Status	2d_canvas: enabledflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onnative_gpu_memory_buffers: disabled_softwarerasterization: unavailable_softwarevideo_decode: enabledvideo_encode: enabledvpx_decode: unavailable_softwarewebgl: enabledwebgl2: enabled
Memory (System)	15.93GB (3.29GB free)
Process Argv	C:\Program Files\MicrosoftVSCode\Code.exe
Screen Reader	no
VM	80%

Extensions List

Extension	Author (truncated)	Version
bracket-pair-colorizer	Coe	1.0.53
vscode-markdownlint	Dav	0.17.0
vscode-eslint	dba	1.4.10
vscode-html-css	ecm	0.2.0
beautify	Hoo	1.3.0
PowerShell	ms-	1.7.0
vscode-icons	rob	7.23.0
html-css-class-completion	Zig	1.17.1

[tomzx]

Both @tommai78101 and @shawmanz32na (#50280) appear to report memory leaks recently. They also share 1 extension in common: vscode-eslint. Looking at the latest releases of vscode-eslint, there have been 2 in the last week, the last tagged one going back to November (although an unpublished 1.4.8 seems to go back March 27).

It might be possible a regression has been introduced in those recent versions, which could explain why both of you experience the same issue in the last few days.

Would you both say that you've started noticing this issue in the last few days or has been a while (more than a week)?

@foxbunny & @svipben, can you also provide the information @tommai78101 shared above?

[foxbunny]

VS Code version: Code 1.23.1 (d0182c3, 2018-05-10T17:11:17.614Z)
OS version: Windows_NT x64 10.0.17134

System Info

Item	Value
CPUs	Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz (8 x 2808)
GPU Status	2d_canvas: enabled flash_3d: enabled flash_stage3d: enabled flash_stage3d_baseline: enabled gpu_compositing: enabled multiple_raster_threads: enabled_on native_gpu_memory_buffers: disabled_software rasterization: disabled_software video_decode: enabled video_encode: enabled vpx_decode: enabled webgl: enabled webgl2: enabled
Memory (System)	15.87GB (7.69GB free)
Process Argv	C:\Program Files\Microsoft VS Code\Code.exe
Screen Reader	no
VM	0%

Extensions (9)

Extension	Author (truncated)	Version
clojure	avl	0.9.8
vscode-eslint	dba	1.4.10
githistory	don	0.4.1
EditorConfig	Edi	0.12.2
vsliveshare	ms-	0.3.198
code-settings-sync	Sha	2.9.2
rewrap	stk	1.9.1
clojure-warrior	ton	0.1.6
wallaby-vscode	Wal	1.0.84

[foxbunny]

@svipben Not sure if that's related to this issue, but yes, I also experience that. Sometimes it does not even take very long (like within a few minutes of reloading the window or restarting VS Code).

[foxbunny]

They also share 1 extension in common: vscode-eslint. Looking at the latest releases of vscode-eslint, there have been 2 in the last week, the last tagged one going back to November (although an unpublished 1.4.8 seems to go back March 27).

For me, this issues has been going on since several releases ago, including the times when I was not using vscode-eslint (on a TypeScript project using TSLint instead). I believe the last release that I did not experience major slowdowns with was 1.19.x, but I can't say for sure.

[Gruntfuggly]

I use vscode all day every day (at work) doing mainly C++ dev (Windows and Ubuntu), but haven't noticed any slowdowns. The only one I am aware of is one of my own extensions which does a lot of entire file formatting (outside the native formatting functionality).

[foxbunny]

I've switched to F# for a few hours, and I can confirm that there is no slow-down. Slow-down only happens with JS/TS code.

[tommai78101]

@tomzx

Would you both say that you've started noticing this issue in the last few days or has been a while (more than a week)?

I can't say if the issue started after the update to 1.23.1, which was at least 1 week ago, maybe even 2 weeks ago, because I started using VS Code exactly 4 days before 1.23.1 was out. I can at least say I just started using VS Code, and the issue was persistent throughout the time I am using VS Code after 1.23.1 to this day.

I've been going back and forth, questioning myself, and feeling in doubt if it was because of me working with a memory-hogging browser (since I always have constant 14GB hogged up with my 16GB rig), or if it's an actual VSCode + ESLint issue. I was pretty hesitant to report anything, until now.

@Gruntfuggly Do you have ESLint or JSHint installed on both Windows and Ubuntu dev environments?

[svipas]

@tommai78101 html-css-class-completion, bracket-pair-colorizer - try to disable these extensions and try again.

[alexdima]

@tommai78101

IMHO, this issue belongs to a discussion forum and not in an issue tracker. As it stands, the issue is not actionable, i.e. I cannot really do any code change and close the issue as fixed. To improve this, I have added follow-up steps to each thing you bring up in order to try to transform this issue into something actionable.

• ACTION: Disable all extensions and check for slowness. We have quite rich APIs and even if the extension host executes on a different process, it is possible for an extension to flood the renderer process with data. You have mentioned ESLint explicitly, can you try using VS Code without ESLint for a while, is that better?

• out-of-the-box, Left and Right keys are bound to cursor movements and they are handled in the renderer process.

  • ACTION: To begin analyzing a slowness in the renderer process, it is possible to create a CPU profile. In some cases, the stacks in there help identify a problematic area. See below for steps on how to create a CPU profile.

• tokenization also executes on the renderer process, in a yielding fashion and it depends on three factors:

  • the grammar being used (configurable via extensions)
  • the theme being used (configurable via extensions)
  • the file being opened

• Tokenization runs in a top-down fashion, and must tokenize each and every line sequentially. For example, if you scroll to line 10,000, all the previous lines must have been processed in order to see colors. As this is done in a yielding fashion (similar to execution in the background), it will take a while for the colors to show. i.e. tokenization is not blocking and you don't need to wait for it to begin doing your work in a very long file. However, it should also not take a ridiculous long amount of time for it to catch up with your scrolling.

• There is one trick worth mentioning, when opening a file again, we will do some trickery to assume what the tokenization state is and will tokenize only the visible region of the file (sort of assuming the top of the viewport is in the initial tokenization state) without going through all the lines above the viewport.

  • ACTION: To begin analyzing a slowness in the tokenization process, please let us know what grammar you are using, what theme you are using and what file is slow.

• Opening a document from the explorer executes on the renderer process. It is possible that you also take a CPU profile of that.

• ESLint can have some impact on the renderer process. Have you been able to come up with some reproducible steps?

---

All in all, I appreciate the issue and thanks for writing all this down, but in order for things to improve, we need to have something actionable that can potentially lead to a code change that improves things.

---

How to create a CPU profile of the renderer process

To get a CPU profile of the renderer process:

• Run F1 > Toggle Developer Tools
• Go to the three dots burger menu
• Choose More Tools > JavaScript Profiler
• Start a new CPU profile
• Do the actions that lead to slowness
• Save the CPU profile to a file and attach it

[tommai78101]

@svipben @alexandrudima

Thanks. I guess I can post here:

https://social.msdn.microsoft.com/Forums/vstudio/en-US/home?forum=vsarch

I think that link above should be in the README.md, considering that it's an actual Discussion Forum.

I will do all of the tests and will post the results tomorrow, since:

• It's close to my time to leave work for the day.
• It takes a long time for VS Code to start being affected.
• It requires multiple testing sessions, so it may even last more than a day.

Yeah, that's all.

---

UPDATE: Wait a minute, that MSDN Forums link is for Visual Studio Code Visualization, not Visual Studio Code.

@alexandrudima Am I allowed to request for an official MSDN Forums dedicated to Visual Studio Code, since it's under the Visual Studio umbrella?

[foxbunny]

@alexandrudima Today I've worked for 4 hours with eslint disabled. It seems that with the current VS Code build, there is no slow-down when eslint is disabled.

[tommai78101]

There was an ESLint extension update while I was testing yesterday morning.

ACTION: Disable all extensions and check for slowness. We have quite rich APIs and even if the extension host executes on a different process, it is possible for an extension to flood the renderer process with data. You have mentioned ESLint explicitly, can you try using VS Code without ESLint for a while, is that better?

It is better. There was hardly any slowdowns and VS Code runs smoothly when the text cursor is traversing through words and characters while holding down Left and Right arrow keys.

Anyway, here's the CPU profile:

ACTION: To begin analyzing a slowness in the renderer process, it is possible to create a CPU profile. In some cases, the stacks in there help identify a problematic area. See below for steps on how to create a CPU profile.

CPU profile.zip. (Moving text cursor up and down during a slowdown phase.)

CPU profile.zip. (Opening multiple documents. Each JavaScript file opened contains about 2000 lines of code on average/ Unfortunately, codes are all company internal codes, so I can't share them.)

ACTION: To begin analyzing a slowness in the tokenization process, please let us know what grammar you are using, what theme you are using and what file is slow.

I'm not sure what "grammar" refers to here in this context, I think it's TextMate TypeScript tokenize2() or something. The theme I'm using is vscode-icons, a very popular icon themes I found online. I'm opening pure JavaScript (no jQuery, no React, no Node.js), Chrome extension project files, for the background and content scripts.

@alexandrudima Is the information provided good enough? Let me know if you need more.

[tommai78101]

Finally, caught a slowdown. (CPU profile)

[alexdima]

@tommai78101 That is a horrible lag! Looking at your latest profile, I can see on the UI process that there is an extension which creates a lot of editor text decorations. It is difficult for me to guess how many those would be, but most likely in the thousands.

Only here the UI stalls almost 400ms to dispose text editor decoration types:

I wonder what precise extensions you are using when the slowdown occurs. You can find the most precise list by running F1 > Show running extensions. You can press the big dot that looks like a recording and then restart VS Code. Run for a bit in this mode (the extension host is debuggable in this mode). Once you experience the slowdown, press the record (big dot) button and that will create a CPU profile on the extension host process. Some graphs should light up showing you the extension consuming most CPU, or otherwise you can also save that one and attach it here.

TL;DR: I believe you have an extension running that uses the text editor decorations API with possibly thousands of such decorations or in a way that causes significant slowdown. Alternatively, the extension could possibly be leaking text editor decoration types.... Leaking would explain why the slowdown takes hours to accumulate.

[tommai78101]

@alexandrudima

TL;DR: I believe you have an extension running that uses the text editor decorations API with possibly thousands of such decorations or in a way that causes significant slowdown. Alternatively, the extension could possibly be leaking text editor decoration types.... Leaking would explain why the slowdown takes hours to accumulate.

I think this may be it. Relative to other extensions, the extension Bracket Pair Colorizer has a profile of 1886.59ms. The second largest profile is TypeScript and JavaScript Language Features, which is coming in at 142.93ms.

CPU-20180529T174916.178Z.cpuprofile.txt.zip

I'll be reporting this over to the Bracket Pair Colorizer and will disable this extension (although, I'm sad VS Code didn't natively come with a highlighter that matches parentheses/brackets pairs with a line) for now. I'm also surprised, unlike Atom, VS Code didn't warn me that there is an extension that is creating a lot of editor text decorations, thereby causing slowdowns.

It's great to have this discussion, as I learned how to profile extensions from all of this. Thanks for your time.

[alexdima]

👍 Thank you for following through with this!

We are not yet at a point where we can trace back automatically slowness in the UI process to the exact extension that made the API call, simply because things are a bit complicated when dealing with these two processes, but that would be something great to implement one day!