VSCode memory leak issue marked “out-of-scope”
github.com
github.com
I stuck with it until recently I found out how to configure VIM to do TypeScript code completion, refactoring, auto-imports, and goto definition. Every once in a while I pop into VSCode to refactor a file rename or some other little piece which I haven't figured out in VIM yet, but I don't miss the CPU and memory abuse a bit.
(Note: I suspect if I invested the same amount of time into Sublime, I'd have equally good results with fairly decent performance as well)
For out code base, having Jump to Definition and refactoring is more-or-less essential.
Configuring CoC is basically copy/ pasta into your .vimrc. It's pretty self-explanatory though so you can figure out what's going on.
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.
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 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...
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.
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.
Thanks in advance for the help.
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.
[just to preempt: for various reasons vim or emacs in a remote terminal do not meet my needs in the same ways]
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.
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).
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.
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-...
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.
C'mon, can't we be above this sort of behavior?
If something is particularly pressing, it will re-appear. It's not ideal, but neither is a large backlog.
This doesn't appear to be a tiny issue either. It is leaking quite a bit of memory rather quickly. They need to find where they're retaining references in one version, but not the other (that kind of thing is what MS pays them for).
A memory leak is bad. Feel free to add a reaction to an existing comment, but spamming the issue thread is counter-productive and gives a sense of entitlement that feels really out of place on an open-source project.
The app had a lot of big video and audio assets split up across various modules. Each language had a bunch of different proficiency levels which each had their own content pack. All the packs together totalled something north of 5 gig so we allowed users to download and install the packs on an as-needed basis.
This fetching code was implemented using the HTML5 FileSystem API (which incidentally was deprecated by W3 halfway through the development cycle, but that's another story). This was great as it allowed us to have this code be completely platform-agnostic!
The only problem was that it had horrendous memory leaks. I was sure we had a bug in our JavaScript code somewhere. We spent A Million Years combing through heap dumps and reviewing our code trying to get to the bottom of it. We tapped contacts at both Adobe and Apple to try and help us figure it out and nobody could.
Until... Until we hit on exactly the correct google-fu to find a a bug report about memory leaks relating to file handles in the WebKit project. We updated our version of Electron and the newer version had a version of WebKit that contained the fix. No matter what strings we pulled, though, we couldn't get Apple to give us any information about what version they shipped on iOS or whether they were likely to incorporate the patch any time soon.
In the end it was moot because the global head office based in the UK got wind of the project and axed it because it might threaten _their_ cross-platform educational content packaging strategy. Which they'd been working on for something like 3 years. Which still hadn't borne any fruit. Nor did it look likely to any time soon. (But that's another story).
Memory leaks can be maddening. The problem is always with your code, it's never in the platform. Except when it isn't and it is.
A) It would be spotted immediately, opening files is core behavior for VS Code
B) The memory usage would continue to grow after closing old files and opening new ones
What this bug is seeing is memory fragmentation and/or reluctance by V8 to release a large allocation block. In either case, those kinds of details are way outside the arena of what VS Code deals with.
Importantly, it's also not anyone's job to explain this to random Github commentators or HN. If the maintainers say its not a bug or outside the scope that's the end of it, and if you don't like that you are free to use other software or fork the project for your own needs.
If it were compaction is there a good reason for this behavior?
This seems very much like they are retaining references somewhere instead. Thankfully WeakRef has shipped with newer Chrome/Firefox and should make some of these things easier to code around.
Some of the extensions have some ornery bugs, but the ecosystem is young yet. The basic editor itself is really nice.
The time to respond was before closing the issue, which the submitter took significant effort to explain with reproducibility steps.
This is poor communication by the maintainers over what seems to be a significant bug; there may be good reason for it being considered out of scope - so it would seem to be more courteous and professional to give it.
(Update D'oh they got Atom with Github long after VSCode)
Then VSCode got really good for an Electron-based app. It's still the quintessential Electron app, even if it trips over things like this now and again.
My speculation is that it had to do with the plugin architecture. Atom was very open-ended; writing a plug-in there, even an intellisense one, was more like writing a browser extension. Your code could just do whatever it wanted, including (easily) step on the toes of other code operating alongside it. You could literally have multiple different plugins implementing an intellisense UI, and then different language plugins would depend on different ones. And then they'd draw over each other, etc. VSCode on the other hand, a) includes lots of frameworks like a debugging UI and an intellisense UI out of the box so that there's a common standard, and b) exposes clean and clear APIs for common stuff, enabling extensions to be much more cooperative with each other and with the editor itself (which not only avoids conflicts, but improves performance too). It's like the iOS app philosophy vs the Android app philosophy.
If I want an IDE that is designed for a specific language? I use IntelliJ for Java/Kotlin projects, Visual Studio for C#, and nothing else really needs an IDE (as in, IntelliJ's siblings based on the same core IDE? I don't really benefit from them).
Where I see VSCode being used the most? Among non-programmers, programmers of beginner languages (Python, Javascript, et al), or among younger programmers that haven't taken the time to learn more ergonomic editors.
I also see it being used among some C/C++ and C# programmers... but I don't get the point, VSCode doesn't even really understand a lot of IDE concepts, for example: it doesn't understand the difference between a workspace and a project, yet gives people the obvious footgun of multi-root projects in the form of a workspace-by-name-but-not-by-concept.
I tried VSCode for like three days, and seriously cannot understand the draw of it for its advertised purpose (Visual Studio Lite), when its really just a code-oriented text editor, and Vim will always be more ergonomic for that purpose (assuming, of course, you're willing to learn how to be ergonomic).
Edit: Also, a lot of VSCode and Atom fans bring up LSPs: I can use those from Vim.
I guess I am saying that its a perfectly valid choice as a ones primary editor. I used it for a couple years and I have nothing but good things to say about it. I just happen to prefer vim + Intellij (with vim keybindings of course!!) :)
That would be great though. Visual Studio then would finally get proper multi cursor support.
I hope not, at least unless VS Code improves heavily
I mean, the real VS has its flaws and is giant, but it has times more reliable intellisense and stuff than VS Code