High CPU usage and poor performance using the integrated terminal on Windows

[seraku24]

• VSCode Version: 1.4.0
• OS Version: Windows 10 - Version 1511 (OS Build 10586.494)
• Installed Extensions: csharp (1.3.0)

Steps to Reproduce:

1. Launch VS Code.
2. Open the integrated terminal (CTRL+~).
3. Type some text into the terminal.

Expected:

The text appears promptly upon entering, and CPU usage shows no spikes.

Actual:

The text does not appear immediately. Task Manager shows one of the VSCode processes is using nearly 100% of a CPU core for around 1-2 seconds. Afterwards, the input text appears in the terminal, and CPU usage drops to minimal values.

Notes:

After rebooting my machine, VSCode initially performs as expected. However, performance will eventually drop considerably and stay consistently poor even after relaunching VSCode. Only a full reboot seems to temporarily address the issue.

While I do not have full Visual Studio or the performance toolkit on this machine to be able to capture more detailed profiling data, I was able to use Task Manager to capture a minidump of the process during the high CPU usage. As the resulting file is about 350MB, I will defer uploading until someone requests it.

DxDiag.txt

[Tyriar]

I haven't experiences any performance issues in particular recently, I spend most of my time on Linux though. I have a few follow up questions:

• Are you using cmd.exe? Does this spike occur in the regular cmd.exe if so?
• What does your setting.json file look like? What is your `%COMSPEC% environment variable set as?
• Which process is 100%? The arguments on the process tell which one it is (eg. --type=renderer, ./terminalProcess, etc.)
• Do you think the overall slow down could be not to do with the terminal?

[jasonboninger]

Hi, I am experiencing very similar symptoms. Running on Windows 7, and to answer your questions:

• Yes, I am using cmd.exe because that is what it defaults to.
• I have not customized any of the terminal settings in settings.json except for the line height and cursor blink.
• I am not quite sure how to answer which process is spiking. Not familiar enough with processes, just can see my CPU usage spike.
• The terminal outside of VSC runs exactly as expected. Instant typing and no performance spike.

Hopefully that helps. I love the integrated terminal, but it so dang slow right now it's nearly unusable!

Thanks for making a great application.

[Tyriar]

Is it possible to right click or double click the process in the task manager to see more detail on it?

[jasonboninger]

I'm sorry, don't know how to do what you are asking in the task manager without much more detailed instructions. I did notice that running VSC all by itself (closing Chrome which where I test my applications) reduces the lag by a lot.

[seraku24]

Hi, @Tyriar. Here are my responses to your questions:

• Yes, I am also using cmd.exe. And, no, I have not experienced poor performance with the CLI itself.
• Here are the only two customized settings in my settings.json:

"editor.snippetSuggestions": "none",
"editor.tabCompletion": true

• Task Manager does not show the command-line arguments, but SysInternals' Process Explorer does. Here is the full command for the process in question:

"C:\Program Files (x86)\Microsoft VS Code\Code.exe" --type=renderer --no-sandbox
 --lang=en-US --app-user-model-id=Microsoft.VisualStudioCode --node-integration=true
 --background-color=#1E1E1E --enable-pinch --device-scale-factor=1 --num-raster-threads=1
 --content-image-texture-target=3553,3553,3553,3553,3553,3553,3553,3553,3553,3553,3553,3553,3553,3553
 --video-image-texture-target=3553 --channel="7024.1.1354609598\1806532456" /prefetch:1

Finally, here is some new information regarding my repro scenario:

After waking my machine from a suspended state (so not a reboot), I found VSCode initially was performing well. I should note the process above does consume around 50% of a core while typing occurs in the terminal, dropping to idle about 1-2 seconds after typing stops.

Unfortunately, it was not too long before the terminal, again, became periodically unresponsive. At this point, I could confirm that the process above is the one spiking. Seeing as the process appears to be related to rendering, it would certainly explain why the visuals are lagging behind the typing.

Since I forgot to include it before, here is a capture of all of the running processes:
Processes.tabulated.txt

[Tyriar]

Thanks @seraku24, so this only occurs when typing? The renderer process is where all the key presses are handled initially before being passed over to xterm.js (Code.exe ./terminalProcess) for processing.

[Tyriar]

This may be related to #9244

[seraku24]

Correct, all of the VSCode processes run at minimal CPU usage normally. Just typing one letter will result in the renderer process taking a lot of CPU.

But what I have found is that you do have to actually type something that changes the console screen buffer. It is not simply the key presses themselves. For instance, pressing backspace at an empty prompt produces no change from minimal CPU usage. As such, it would seem the performance is not really tied to the input itself but whenever the console screen buffer is altered. This appears to match the behavior described in the issue you mentioned.

[carlin-q-scott]

I tried using the integrated terminal for a node.js project in Windows but it greatly reduces performance of all the npm commands, especially "npm install". npm does a fair amount of fancy stuff with the terminal so I'm guessing it's not helping the performance but the difference between "Integrated Terminal" and a normal command prompt is stark.

[codec-abc]

I made some profiling of VSCode. I did the following:

• Wait for a few seconds
• Hold down a key
• Wait for a few seconds

Here are the result in the profiler :

We can clearly see the spikes that cause the slowdown but I don't get much information from that. Is there any way to get more details using the debugger tools ?

[codec-abc]

This looks like xterm.js fault. I can have good performance by modifying the xterm.js file packaged with vscode (C:\Program Files (x86)\Microsoft VS Code\resources\app\node_modules\xterm\src\xterm.js) and doing either of the following:

Hacking line 2795 from to

this.refresh(this.refreshStart, this.refreshEnd);

to

this.refresh(this.refreshStart, this.refreshEnd, false);

or

Hacking line 1486 to 1488 from

setTimeout(function () {
            self.refresh(start, end, false);
          }, 34)

to

setTimeout(function () {
            self.refresh(start, end, false);
          }, 0)

The solution is from what I could understand from xterm.js, either to force the refresh to happen automatically or to force the refresh to happen more often. By default, the refreshes seems queued and I suspect them to not happen enough on some configurations. I still don't understand why on similar configurations we have such different results.

Edit : A better solution may be to force the refresh when we receive something from the terminal. Adding the following (tested only on the generated js file) after this line seems to work.

this._xterm.refresh(this._xterm.refreshStart, this._xterm.refreshEnd, false);

[Tyriar]

Thanks a lot for this @codec-abc! I actually wrote that queue/refresh logic in order to allow xterm.js to not lock up when the terminal receives an enormous amount of output. I don't totally understand just yet why this is only happening on Windows but this is a fantastic start! I was assuming the problem lied within pty.js. I've opened xtermjs/xterm.js#280 to look at this over there.

[codec-abc]

I made more tests and its seems the problem is not really deterministic (meaning that I can open the same editor twice and the terminal will be laggy some time but not always) From the tests of yesterday I am quite sure that the problem don't come from pty.js as I had still a laggy behavior with the lib commented out. It seems like a DOM performance problem that is not always triggered.

[codec-abc]

I re-ran tests on the master branch and I have found interesting things.

• The terminal is a lot faster than the 1.5 version but still not smooth by default.
• The hot fix that consist of setting the timeout to 0 work in a reliable fashion.
• The electron package has been upgraded and thus the debugging tools are way better.

Below you will find screenshots (because the save timeline feature of dev tools does not work) of the timeline (running the master branch) when I kept a key pressed in the terminal.

This is a capture with the setTimeout of 0

And those are captures with the default value of 34

From a look at the close-up, can it be that the slowness is only due to the fact code that will issue a repaint happen 34 ms later than when a key was pressed ? Because then we have to wait to the xterm code to execute (1-2ms) will which will trigger some layout (5ms) then painting (5ms) and finally waiting for V-sync. When we add the number we are not far from the framerate given by chrome (~20fps).

I hope this can help. I ran out of idea to debug/diagnose what is going on but if you need help to test something I will gladly help.

[hickeng]

I'm using "terminal.integrated.shell.windows": "c:\\Windows\\sysnative\\bash.exe" and it's excruciatingly slow. More so that cmd.exe was.

[carlin-q-scott]

Was something done to address this in the past couple weeks? The integrated terminal has started performing as well as standalone terminal in Windows 10, for me at least.

[Tyriar]

@carlin-q-scott the only thing I can think of is that the xterm.js library would now be optimized a little more by going through the babel compiler, I wouldn't expect that to fix the problem though.

[jasonboninger]

@carlin-q-scott I may have noticed a slight performance improvement (could even be in my head), but it's still extremely laggy compared to using the command prompt itself.

[codec-abc]

Installed the 1.6 on my home computer. Terminal is smooth (There is some subtle "lag" that can almost only be perceived when keeping a key pressed, but I am quite sure this due to xterm.js limiting the refresh rate to 30fps) .

I wonder if this was related to a bug in Chrome that could have been fixed with a bump of the electron version.

@jasonboninger What version are you using ? If you are using the last version, would you mind using the chrome dev tools to profile vscode while you type something in the terminal ?

[jasonboninger]

@codec-abc I just upgraded all my VS Code installations to 1.6 as well. Again, it seems there might be a slight improvement, but I'm definitely still experiencing very sub-par performance.

Can you give me some basic instructions on where to find and how to use Chrome dev tools to do what you are asking? I've never used them before besides in browser to inspect web pages. I'd like to be as helpful as possible though.

[codec-abc]

@jasonboninger The Chrome dev tools are available in "Help -> Toggle Developer Tools". The most interesting thing in our case is to the Profiles tab. Focus it then select the "Record Javascript CPU Profile" option. Then, click the "Start" button and go back to vscode to do reproduce the case where you encounter poor performance. My default test is to kept a key pressed to quickly fill the terminal for ~10s.

With the previous version of Electron most of my timelines were filled up with a native code operation without detail. Hopefully, you will get something better thanks to the new Electron packaged with vscode 1.6.

[jasonboninger]

@codec-abc Wow, never noticed that menu option before. Will try this tonight and hopefully will be back with some profiles! Thanks!

[hickeng]

Massive improvement for me in 1.6

[Tyriar]

This may actually just be a matter of raw computing power, if possible can people state how they would classify performance in 1.6 in addition to the CPU speed/cores and RAM their computers have?

[jasonboninger]

I tried to output a timeline captured from inside VS Code but unfortunately the file didn't save and I'm not really sure what it was capturing. In lieu of that, I noticed something else that seems even more indicative of the/a problem:

I opened Task Manager and did the @codec-abc test where I held down a key in the integrated terminal in VS Code. Attached is the result. The first part of the performance graph shows peaks at 7%-10% CPU usage simply by holding down the "a" key. Every time I stopped, the graph would go back down, then I would hold "backspace" and you get another hill. I did this a few times back and forth.

Next, I opened the Command Prompt itself. The entire last piece of the graph I was either holding down the "a" key or holding down "backspace". Unnoticeable CPU impact. This is what I would expect from simply typing input.

So, processing power may help cover the issue but it is not the issue itself in my opinion. And I ran the above test on my desktop which has 16GB of RAM and a i7-4790 @ 3.60GHz. It sure seems to me like if VS Code's integrated terminal is taxing 7%-10% of a quad-core 3.6GHz processor, then there is something going on.

If there is anything else I can do to help shed light on the problem please let me know. I can try running the Chrome debugger again if anyone thinks that would be useful to get more detail. I know I'm only presenting evidence and not a solution and I'm sorry about that. I love VS Code and having a seamless integrated terminal would simply put me on cloud nine. Thanks to all of you out there working on troubleshooting these and any other bugs that people like myself find.

[codec-abc]

@jasonboninger I got the exact same behavior before the update. The save function in the chrome dev tools does work. It is unfortunate, But you can post screenshots of the profiling graphs if you find something interesting. By the way, would you mind doing a clean install of vscode (and deleting the directory of your current installation) just to be sure.

[jasonboninger]

So the behavior I noted above changed for you? That could be very good news.

I'll give doing a clean install a shot, and hopefully it fixes the issue. If not, I'll wrestle with the debugger until I can save something that seems useful.

[codec-abc]

@jasonboninger Yes, the behavior changed for me. And it seems this is also the case for @carlin-q-scott and @hickeng . This is why I asked you to do a clean install because if the bug is still there then it happen to fewer people than before which would make it even harder to debug. And thanks for investing time in this.

[jasonboninger]

Ok, I'm happy to hear that thing are working well for some people! Here is what I did:

1. Uninstalled VS Code
2. Restarted my computer
3. Installed VS Code
   Unfortunately, the CPU spikes and integrated terminal performance remained identical. Is there anything else that I should do besides uninstall to make sure I wipe out things that could be causing performance issues? All of my settings came back without my having to do anything after re-install but I verified that the Programs folder was gone.

Secondarily, when I try to save timeline information it creates a 0kb JSON file. I tried in several locations on my computer with no luck. Perhaps I have more issues than I thought! I've attached a screenshot for you reference. The debugger loads with the error circled at the bottom and the circled portions of the timeline itself are the points when I am holding "a" and then holding "backspace".

Especially, if this issue is becoming more obscure, I am hoping to provide more information. Not sure what is up with my install given the weird timeline can't save quirk that is also occurring.

Any advice is appreciated!

[Tyriar]

From that timeline it looks very similar to what I've observed on Linux in xtermjs/xterm.js#280 (comment), maybe Windows is just slower at dealing with the barrage of scroll events that occur.

[codec-abc]

@jasonboninger Thanks for sharing your screenshot. There is a bug in Electron that prevent it from saving a profiling correctly. Until, it is fixed the only way to share profiling results is to do some screenshots. About the error in the console, I got it too but it seems benign. Lastly, could you do a close-up screenshot for a long frame in the portion where you keep a key pressed. It would be great if you can share what it's in the Bottom-up and Call Tree tab too. You can select a frame by clicking a red rectangle in the timeline that is just above the Interactions ones. It is easier than moving the slider in the bigger timeline.

[jasonboninger]

@codec-abc Will do! You should hear from me later today.

[jasonboninger]

Alright, here are some more detailed looks! Hopefully, they figure that saving bug out and then I can share the JSON itself with those who know more about troubleshooting than I do.

[codec-abc]

Thanks for the screenshots. You might find it surprising, but after looking at them I would say that you don't suffer from performance issue. When filling the terminal while holding a key, you have a more or less a stable framerate at ~15fps. Which is why I have on my computer now. Before the update the framerate was at least 5X lower. Moreover, The timeline shows what I would expect :

• The CPU doing nothing most of the time because of the 34 ms delay between the keyboard event emitted by Electron and the start of the DOM's update in xterm.js
• A fair amount of time doing layout and rendering

[jasonboninger]

To me, 15fps isn't stable. The eye will start to distinguish lag with anything below 24fps so 15fps bothers me when typing quickly or holding delete to go back. I did the same key hold test in Chrome inside this text box that I am typing my comment in, and the browser maintained 30fps. Perhaps it isn't possible to achieve in VS Code, but I think it is hard to argue that 15fps is production level performance even if it is stable.

However, to your point about the CPU usage, I saw the same spikes in the Task Manager for my CPU usage in broswer as in VS Code so I guess typing isn't trivial in a web browser / Electron environment unlike natively.

Based on your response, it seems you feel like we've left pure "bug" territory. And you're probably right, the integrated terminal is usable, and I'm not going anywhere just because the terminal isn't a rock solid port of native performance that I'm used to. But in a world of package managers and version control that are even more useful with terminal access, it seems like a worthwhile investment to make it solid. I'd be out there selling VS Code on the street if the terminal were perfect, but instead it's a compromise in performance that I'm more than willing to put up with for other awesome features.

Thanks for taking the time to explore this with me. Just the input of one user.

[codec-abc]

I agree that 15 fps is not great performance. And you are wrong when you say that the eye distinguish lag with anything below 24fps. It happen way before that. I can tell the framerate of any game with a +/- 10 fps margin. And I am quite sure that If I buy a 144Hz screen I would be able to feel the difference between 60Hz and 144Hz.

Anyway, concerning this bug, I think we can close it now as it the problem of very poor performance seems to have been fixed with the upgraded version of Electron.

Still if you want to argue about the framerate to the terminal (for which you have some valid arguments) there is an issue in sourcelair/xterm.js#280 that is more related to the low framerate of xtermjs. By the way, if you want a smoother terminal, you can try the "fix" I provided earlier in the discussion (setting the timeout refresh to 0 ms). By forcing the refresh of the terminal as soon as its content has been modified you will have a more responsive terminal.

[jasonboninger]

I appreciate your understanding, and I agree with your assessment of the situation. I am a bit afraid of hacking the core of anything so I'll just keep plugging away as is for now. Thanks again for all the help. Will probably start to loosely follow the xterm thread as integrated terminal performance is the closest thing I have to a complaint about VS Code at the moment.

[optyler]

I got high CPU usage too on OSX

• VSCode Version: Code 1.7.1 (02611b4, 2016-11-03T13:46:00.226Z)
• OS Version: Darwin x64 16.1.0
• Extensions:

Extension	Author	Version
EditorConfig	EditorConfig	0.3.4
vscode-eslint	dbaeumer	1.1.0
sass-lint	glen-84	0.0.3
sublime-babel-vscode	joshpeng	0.2.2
sass-indented	robinbentley	1.2.1
react-redux-es6-snippets	timothymclane	1.0.5
JavaScriptSnippets	xabikos	1.2.0
Material-theme	zhuangtongfa	1.0.3

---

Steps to Reproduce:

1. Launch VS
2. Navigate through your project files
3. about 5 minutes, fan is rotating fast and CPU is pretty high, in Activity Monitor panel, Code helper takes between 100% and 150% of the CPU.

[Tyriar]

@optyler this issue is about the terminal on windows, you should file a new issue around general usage CPU on mac.

[optyler]

@Tyriar oh, sorry, I'll do it.

[Freddixx]

I'm on 1.9.1 and it's indeed still really, really slow. vscode's CPU usage is at 2.9% - so not even really high. But jobs such as adding / linking packages on yarn take forever compared to running it in a "normal" powershell.

[Tyriar]

The original issue here is fixed with the performance improvements in v1.9, the terminal front end (xterm.js) was optimized in #17875, most notably for this issue the queue mechanism only firing every ~30 frames is now gone. winpty was also upgraded which fixed a slew of Windows problems.

[amer1616]

I have a similar issue with the integrated powershell. it's almost slow and freezing while downloading npm packages. the external powershell is ok & fast to download