Vscode: Improve performance of vscode while being accessed remotely

[nateman1352]

• VSCode Version: 0.10.11
• OS Version: Win7

Editing code on a remote system is currently a bit slow when using Visual Studio Code. Scrolling in particular seems to take longer to redraw than other editors like full visual studio or notepad++. It would be a great new feature if the GUI was optimized to redraw faster over remote desktop.

[egamma]

Can you elaborate what you exactly mean by remote access? Remote desktop access? Working on a folder that is mounted from a remote file system?

[nateman1352]

Remote desktop access. Specifically, running visual studio code on a remote computer and using the editor in a RDP session. It redraws slower than other editors over RDP. It's particularly painful if you are on a low bandwidth connection like a corporate VPN for example.

[alexdima]

We need to investigate if it possible to determine if there is a RDP session in progress and perhaps render things differently. We can start with disabling all animations for example.

[bpasero]

I would love to find out if VS Code runs inside a VM, if someone has ideas how to detect that, please let me know.

[wgv-sethlivingston]

I'm seeing very slow RDP rendering performance, particularly when typing, in 1.10.1. Disabling animations would be a great start, I think, even if it isn't the source of the performance problems I'm seeing. JetBrains disables animations over RDP, too.

Update:

I just turned ESLint from onType to onSave, and that significantly improved things.

[thomas-darling]

Yeah, this _really_ needs to improve!

It is especially bad when animations are running, such as the small spinning bar at the bottom left that appears while running a task, or the blue progress indicator that appears above the git panel when it updates. That little spinning bar alone can keep the connection so busy, that the screen basically _freezes for several minutes_ - it is so bad, that it can actually make the RDP session unresponsive.

If there is no easy way to detect a RDP session, then at least provide an easy way to turn off all animations - especially the long-running ones, but also any fade effects triggered by mouse over.
That would be a good start - and much needed!

[markmnl]

X11 perf too! Probably the same cause?

[danielschenk]

I'm having the same issue when using X forwarding. I'm using an SSH session to an Ubuntu 16.04 machine from Windows (using MobaXterm) and launching code from the shell.

[lqueryvg]

Hi all,

I've noticed performance issues too (scrolling and resizing the sidebar are particularly laggy), but "remote access" is ambiguous and perhaps needs clarification.

There are (at least) two ways to run VS code remotely, so there could potentially be two separate issues:

1. RDP
2. X11

Or they could both be related. ;-)

I'm using X11 to run VS code inside a Linux VM on a Windows 7 laptop (I'd be happy to help someone setup this environment in order to reproduce the problem).

Like this:

• laptop runs Windows 7
• Linux runs inside Virtualbox VM (via NAT virtual network)
• Windows runs an X server (MobaXterm in multiwindow mode)
• VS code runs inside Linux and displays (export DISPLAY=10.0.2.2:0) to the X server via the virtual network

(I prefer this to RDP because the windows running in Linux can be properly integrated into the outside Windows desktop.)

Other tools don't exhibit the same lag. E.g. PyCharm graphical performance is almost as good as native Windows.

I suspect it's to do with the way that VS Code is using the X server. I've done a bit of X programming in the past and the idea is to do all of the graphical output using graphics primitives, e.g. draw lines, boxes, characters (which are loaded once into the X server). I wonder if VS code (or Electron underneath it) is pushing pixels to the X server instead - which is not the ideal. I wonder if Atom has the same problem ?

@danielschenk, check you are using compression on your ssh session - I found it improved performance for me quite a lot (even via the virtual network, which surprised me!), but performance is still not ideal.

[lqueryvg]

FYI, I just tried Atom (VS code and Atom are based on the same Electron framework) and it is also laggy via X11 over my Virtualbox virtual network.

[DaelonSuzuka]

I'm also having bad lag problems with remote VS Code access. I'm using X11 to forward from an ubuntu 16.4 box to Windows 10 machine across my LAN.

[yoisel]

One quick fix that could help a lot all rdp users would be to add some kind of debounce effect to scroll events. Currently if we move a scroll up and down we have to wait for all the events to be processed before being able to type again.

[bdonnahue]

Im having the same problem running vs code over x11. It is hosted on a centos virtual box vm on my laptop. I am ssh'int to localhost

[80220]

I have installed vs code 1.27.2 on VM(set up with VirtualBox/W10), tried VM with CENTOS 7(C++ extension installed) and VM with FEDORA 28 (Python extension installed). I'm running it from shell over SSH/X11 and scrolling the python/cpp file kills CPU (I have 2 vCPU/VM). SSHD daemon has 70-100% usage of a core and it gets very laggy. Pycharm Community has no such problem.

[pgaskin]

I've been having the same issue on Debian and Arch with the latest x11vnc. I've tried on GNOME and XFCE. I've also tested with RealVNC, and TeamViewer.

The funny thing is, this issue doesn't seem to appear when using i3wm (tested with the x11vnc and RealVNC). If someone could try this (i3wm is pretty lightweight, and is simple to install on most distros) and confirm, it would be nice. The main difference I can think of is that unlike GNOME and XFCE, i3wm doesn't use a compositor.

[80220]

I also checked, that Pycharm Community (when scrolling) also increases SSHD CPU utilization, but it goes at most to 10-12% not above 70% (checked with top command). So JetBrains seemed to optimize for X11 protocol. I don't want to install full GNOME/KDE, I always do minimal VM installation per project and add only what's needed.

[pgaskin]

@80220 JetBrains products are different. The lag happens with Chrome, Atom, VSCode, and other chromium-based stuff.

Can you try with i3, like I mentioned in the previous post?

[bdonnahue]

I am on an i5 (issue mentioned previously)

[pgaskin]

@bdonnahue I mean i3wm (the tiling window manager), not the intel processor.

[80220]

I can see i3 is not avail for W10. I want VMBox/W10. So I can not check it.
Anyway this post: http://dustwell.com/how-x-over-ssh-really-works.html describes the setup with X11.
It seems to me, that X-Client (either VS Code or Jetbrains) needs to establish some IPC to: "sshd spawns a new process that is an X-server-emulator listening on some display number". And in case of VS Code this communication is not optimized and kills SSHD process, what is the root cause of lags(Chromium too chatty?). I don't know but if it's some core problem with software, vscode is run on, then maybe it is not easily fixable. Regards

[pgaskin]

@80220, I didn't know you use Windows 10. You could still install i3 in a VM, and start it along with x11vnc. Then, you can access the desktop with a VNC viewer.

Also, what I was talking about is using it over VNC. VNC is an image-based protocol, unlike x forwarding.

As for it being a core problem, it seems to be that way, as Chrome and Atom has the same issue.

[SoreGums]

working pretty smoothly now on local Windows 10 Hyper-V archlinux guest vm via vnc / i3-wm / realvnc client.

how i set it all up here: https://gist.github.com/SoreGums/28f21f5ad724b4e8658c07f1999f5af1

[pgaskin]

There seems to be a regression in vscode 1.31.1 with i3wm and RealVNC 6.4.0. It's quite laggy when updating the screen (seems to only update every 3s). This doesn't happen when downgrading to vscode 1.30.0. I'm going to try a few things and see if I can figure out why.

Edit: the issue is back on 1.31.0. I'm going to try this in a VM from scratch.

Edit: seems to work fine (at least for the last few minutes) with --disable-gpu. The funny thing is it is quite intermittent. Without this flag, sometimes it gets laggy instantly and other times it takes a few minutes. With this flag, it seems to work more consistently, but I'd need to test it a bit longer.

[gatopeich]

v1.32.3 here, "--disable-gpu" does not seem to help with lag on my setup (Ubuntu 18 -> VPN -> Ubuntu 18)

[halsafar]

Running VSCode 1.3.2 on a Centos 7.4 server.
Accessing it over NoMachine, MobaXTerm, Exceed on Demand.

In all cases above it has some major usability issues that kills it for most of our devs:

• Scrolling lags so much that using the mouse wheel is out.
• Large source files exacerbate the issues, typing becomes laggy.

As a comparison:

• PyCharm, CLion (IntelliJ) IDE's work great in the above remote access tools.
• Eclipse suffers the exact same as VS Code on any remote access tool.

[pgaskin]

@gatopeich I have been using VSCode without the flag for the last week or two, and haven't had any issues. The unusual thing is nothing has changed (I'm using the same connection, the same software versions, etc), but it seems to work fine. I can't reproduce it consistently in a VM either ... FWIW, I've never had this issue with older electron versions, and haven't run into this issue on Chrome for a while now.

@halsafar What's the delay like when hovering?

Also, I think this should be a bug, not a feature request. This issue makes VSCode completely useless during remote access when it happens.

[halsafar]

@geek1011 When I hover something it takes ~1s for the tooltip to appear. That is fine to me.

I do notice that pop up windows almost always open on the wrong monitor. File -> Open for example always opens on my first monitor even though VS Code is on my second monitor.

I also notice that very tiny source files ( a few lines ) seem to work perfectly. However it doesn't take much for things to start lagging.

--disable-gpu seems to make it a bit better but that might just be placebo.

Edit:
--disable-gpu and disabling smooth scrolling seems to make scrolling almost perfect! Still room for improvement as the files get larger.

[gatopeich]

I have been using VSCode without the flag for the last week or two, and haven't had any issues. The unusual thing is nothing has changed (I'm using the same connection...

@geek1011, Did you check your connection latency with ping or traceroute?

I get 40 to 100 ms, which can be pretty bad for real-time stuff, however most other editors work like a (py)charm!

SublimeText was terrible too, with its custom rendering engine (who thought that would be a good idea for a code editor???), but I have the feeling it was recently improved to not-so-bad state.

[pgaskin]

@gatopeich I usually have around a 19ms RTT.

[gatopeich]

@gatopeich I usually have around a 19ms RTT.
Well that is a big improvement over my best case 40 ms :-)

For the record, I use X2Go so it should be very similar to NoMachine ~ NX

[Tyriar]

We just announced remote development with VS Code, check out the blog post for details https://code.visualstudio.com/blogs/2019/05/02/remote-development