Hi, I'm a developer on VS Code and wanted to clarify that there was actually a logical memory leak in there.

The problem is that I tried to reproduce it back in October while running from sources, and I could not reproduce any leak. I believed the issue is about the memory usage reported by the OS vs the memory usage reported by the logical JS Heap Snapshot, which is a common topic for garbage collected runtimes, such as JS / v8. That is why we believed the issue is about the v8 VM not freeing memory back to the OS when we freed memory logically.

But it turns out I tried the steps again just now, and there is a real memory leak in there! It only reproduces when running a built version of VS Code, such as VS Code Insiders or VS Code Stable. The built versions of VS Code offer file type extension recommendations, for example you open a `.php` file and a recommendation comes in to point you to the PHP extension. When running out of sources, those recommendations do not show up and the entire code responsible for those does not execute.

Thank you for bringing this up to my attention and I'm sorry for misunderstanding the initial issue.

> the Code Helper uses massive resources and about once every couple days ends up spinning out of control causing the CPU to cook and the fan to spin constantly until it's restarted

What language are you working in?

VSCode's user experience varies widely between languages/ecosystems. Its IDE features are driven by language servers, and most are written by third-parties, and some of them are great and some of them are terrible. TypeScript and Rust (if you're using rust-analyzer) are stellar. Python is okay. Flow (an alternate JavaScript type system) was terrible last time I checked, spinning the CPU and freezing up like you describe. Language servers run as a separate process (Code Helper, I believe) and can be as inefficient/leaky/resource-hungry as they want to be.

We're straight TypeScript/ React. We have a pretty large codebase though which no doubt contributes to the issue.

The thing is, VIM uses the same language server and (so far anyhow) doesn't melt down. It seems like the issue is in the Code Helper process itself.

I have heard of people running into issues with the file-search indexer taking a long time on extraordinarily large projects. The largest project I've used it on was in the thousands of files (excluding node_modules) and didn't have any issues. But I know there are much larger projects out there, so I can't speak to those.

We're approaching 3000 source files in our repo so I'm not sure. That is the issue.

Here's a question: are you using git, and is node_modules ignored?

I ask because I think VSCode (by default) leans on the gitignore to decide which files to index. If it's indexing node_modules for whatever reason, that could create some serious overhead.

https://www.reddit.com/r/vscode/comments/fpfnle/is_there_a_w...

node_modules is in our .gitignore.

I'm not sure I was super clear above, but I'm not too worried about fixing this. Now that I have a good VIM configuration I just don't feel the urge to go back.

That's fair! Cheers

Also, thanks for being rad! I do appreciate the suggestions!

Do you have tests and install any test plugins? I found out after a while my fan was blazing because a plug-in was auto running all the tests it could find in the background. Once I turned that off it’s been tolerable.

For some reason VS Code will hang and not allow interaction or input for around 25-30 seconds. I have noticed this mostly when deleting a Python file and sometimes while editing Python. How might I debug whatever is blocking the main thread to find out if it is the language server or something else?

* Firstly, may I ask are you using Vim extension? * Can you please follow instructions listed here https://github.com/microsoft/vscode/wiki/Performance-Issues#... to profile the renderer process when that happens (more accurately start the profile before the hang happens and stop after). Usually extension should not block the typing so it might be something bad in the core. Once you have it captured, please file an issue

Thanks in advance for the help.

That's crazy. I use it on a small-medium Python project (100-200 files) every day and have never had any performance problems whatsoever. I did use the MyPy language server at first, which would take a few seconds to update type errors because MyPy wasn't designed for IDEs. But the UI thread remained responsive during that time. Eventually I switched to the Pylance language server which doesn't do a perfect job with checks, but gives feedback instantly.

How big is your project, and how big are your files? I've had massive JSON files (100MB or so) cause some slight jank in the UI, but that's about the only example I can think of.

I have the same problem, but I think it's an extension issue. On Ubuntu it happens, but with same extensions on macOS is not happening. I wish i could debug it. In my case it happens only when deleting files from the source tree

vscode's remote mode is what pulled me away from sublime. There's just nothing like it in any other editor and it's becoming indispensable to my particular workflows.

[just to preempt: for various reasons vim or emacs in a remote terminal do not meet my needs in the same ways]

> There's just nothing like it in any other editor ...

Emacs has had TRAMP[1] built-in for a while now[2].

1: https://www.emacswiki.org/emacs/TrampMode

2: https://www-cdf.fnal.gov/~cplager/cygwin/useful/emacs/tramp-...

I've seen it and it does look cool. I seem to recall there is a way of pair programming with VSCode which could be pretty rad too. I have no need for either of those features, but I can totally see them being a game changer in certain circumstances!

It's a shame Remote SSH etc are closed source and MS has no plans to open them. The extensions even check and refuse to run under non-MS vscode builds.

Can you explain a bit more about the usecase remote supports?

I use vscode-ssh to offload the heavy work to my desktop when working from my laptop.

The big deal is that vscode uses a client/server setup, where a "client" vscode instance runs on your machine and a "server" vscode instance runs on the remote one. Then they figured out how to make latency and/or network intermittencies a non-issue. The experience is basically the same as working locally, except the linter, language server, formatter, and compilation run on the server-side (and hence don't bog down my laptop in this case).

Then there are quality-of-life touches, such as vscode offering to tunnel ports whenever you launch something in the integrated terminal that listens for connections. That is: let's say I run "python3 -m http.server" in the terminal within vscode (where I'm working on a remote project). The http server is launched on the remote machine, and I get a prompt asking me if I want to setup a 8080 (laptop) -> localhost:8080 (server) tunnel.

I was an adept of Jetbrain's various IDEs (and smart completions are still better there for most languages), but vscode-remote works so well that it has won me over.

Not long ago, a friend of mine was considering a new laptop. He was happy with his pixelbook in general, but working in the "c++ with lots of number-crunching" space the pixelbook wasn't cutting it. I gave him an account to my desktop machine to let him try, and he's now a happy owner of a nice workstation for much less than what the laptops he was considering cost. Important point: my desktop uses a residential connection in Spain, and he's in the US. He had 0 issues with latency whatsoever (and I can attest the connection itself does have such problems).

That sounds great!

The Remote - SSH extension allows you to run Visual Studio Code on whatever computer you want to run it on but then remotely connect to another computer such that your files are on the other computer, your code runs on the other computer, and the integrated terminal can run on the other computer. So it's like SSH on steriods, where your editor and IDE works, including all the extensions you'd expect.

So for example, instead of going through the hassle of building Visual Studio Code on Raspberry Pi, where there's no official support, you can simply use the Remote - SSH extension to develop directly on the Raspbery Pi from a Windows computer. This really shines when the Linux machine you're connecting to is headless.

The Remote - WSL extension allows the same thing but in a more direct way by connecting to a WSL installation on your Windows computer.

https://code.visualstudio.com/docs/remote/remote-overview

This feature is also why I've recently been using Visual Studio Code more and more. I think something like Emacs, once you learn it and spend a huge amount of time on, would be more performant and snappy in the end, but Visual Studio Code has too many modern features and a rather frictionless configuration and extension experience that keeps me there.

I use it for developing inside docker containers. We have a dockerized Apache Airflow setup for which I am adding plugins. Remote VSCode allows to work inside one of the containers spun up by docker-compose, so I do not have to simulate the environment the final system is running in. Think of it as python venv on steroids.

Another use case is remote ssh where I can work on a headless system with a graphical editor. I use it e.g. to work in a minimal Linux VM from my Windows desktop.

The remote docker plugin is a little fiddly to setup, but once running works pretty good.

I think one use case would be working inside of a Docker container, locally or remote.

Do you have your setup documented? I have been checking out Vim for TypeScript once a year or so and have not had complete luck, with plugins either requiring specific versions of Python and modules or just being unstable for the more advanced features.

I posted a little about it in another reply on this thread, I use ALE for JSLint/ Prettier integration and for Code Completion and quasi-IDE like features I use CoC.

Configuring CoC is basically copy/ pasta into your .vimrc. It's pretty self-explanatory though so you can figure out what's going on.

https://github.com/neoclide/coc.nvim

What did you settle on for you vim plugin? ALE, coc?

Yes, that was my ultimate solution. I tried a different auto-complete plugin previously and it was disappointing which is the reason I've been on VSCode for so long.

FWIW, I found out about CoC on a recent thread here on HN.

For out code base, having Jump to Definition and refactoring is more-or-less essential.

Sounds to me like you have underpowered hardware. I use it constantly for all kinds of tasks and the fan never even spins up. I haven't heard "spinning out of control causing the CPU to cook" anywhere else

> Sounds to me like you have underpowered hardware.

It's a text editor. It should run fine on whatever hardware I have. In this case, it's a fairly modern 15" MacBook Pro so even a full featured IDE should be just fine.

It has happened to me with some frequency. Sorry but I dont buy the under-powered hardware excuse when vim or Sublime perform great in the same computer. And for the record I really like VS Code, but I am not deluded.

Underpowered hardware for Electron apps runs giant IDEs for Java development with ten times the features just fine.

Which Java IDEs are these?

Eclipse and Android Studio are both monster IDEs

Also, while Intelij is better than Eclipse, it's a bit of a pig too. Not crazy bad like Eclipse was, but bloated enough.