6 ms·

VSCode memory leak issue marked “out-of-scope”

62 points by hajile 6y ago

symlinkk 6y ago
Probably because it’s an Electron issue, not a VSCode issue? How about we let them respond before freaking out
- curmudgeon22 6y ago
  Well, they closed the issue 21 days ago... if that’s the case, they could at least add a comment to that effect.
- mellosouls 6y ago
  Where have they indicated that it's an Electron bug when closing the issue? 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.
ogre_codes 6y ago
I've used it on and off for the past 14 months, but I have little love for it. I know VSCode is more or less the industry standard. But coming from Sublime Code, the performance of VSCode is pretty mediocre. On top of big memory demands, 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. 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)
- candiddevmike 6y ago
  What did you settle on for you vim plugin? ALE, coc?
  - ogre_codes 6y ago
    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.
  - ogre_codes 6y ago
    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.
- 0x6c6f6c 6y ago
  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.
  - ogre_codes 6y ago
    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 https://github.com/neoclide/coc.nvim
- brundolf 6y ago
  > 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.
brundolf 6y ago
The lack of a public explanation is bizarre, but surely there must be an explanation internally. Does anybody have any insight?
- deleted 6y ago
  [deleted]
- nickelpro 6y ago
  V8 having non-ideal memory compaction behavior for any given benchmark isn't something that the VS Code team has any amount of control over.
  - brundolf 6y ago
    What makes you think that's the problem? And if it was, they could easily put a cap on this by telling people that's why it's out of scope
    - nickelpro 6y ago
      The memory usage doesn't grow indefinitely, it's not a leak. Opening a large file, closing it, then opening more smaller files doesn't cause further growth. If VS Code was holding onto old references from opening files: 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.
      - hajile 6y ago
        The original filer stated that an identical electron version on older builds didn't have the same issue. 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.
johnfn 6y ago
What? You expect the VSCode maintainers to write up a lengthy explanation for why they have to mark every one of their 100k closed issues as closed? Are we really ascribing malice because they didn't do that once? C'mon, can't we be above this sort of behavior?
- basicneo 6y ago
  +1. It's reasonable for projects with large backlogs to do a quick prune with lower quality, either via manually or via tooling. If something is particularly pressing, it will re-appear. It's not ideal, but neither is a large backlog.
- hajile 6y ago
  They didn't even ask for more details. They obviously didn't attempt to reproduce anything. They just closed the issue. The person who filed later noted that identical electron versions in earlier VS Code editions do not have the same problem. 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).
Scarbutt 6y ago
SublimeText's author single-handedly supported windows,macos and linux from the start, what was Microsoft's reason to choose electron? I have never used ST and Microsoft probably picked electron to capture the huge web development market and also provide a cloud IDE for it's cloud offerings, but it's worth noting that vscoded is touted as an "exemplar" electron app only because a big well funded team is doing thousand and thousands of micro-optimizations all the time full time.
- ogre_codes 6y ago
  Didn't they buy VSCode? Or Fork Atom early on or something? (Update D'oh they got Atom with Github long after VSCode)
  - bovermyer 6y ago
    Microsoft initially added Intellisense to Atom and called it VSCode. It was not great, but better than Atom. 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.
    - brundolf 6y ago
      It's funny, because Electron was literally invented for Atom (note the wordplay!). I was a long-time holdout for Atom; I didn't want to ditch the original for the Microsoft takeover. But eventually I had no choice but to relent. Atom just got really sluggish once you had a few plugins running, and VSCode runs like a dream. 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.
HerbsMan 6y ago
Not sure why people using VSCode... it's big, slow and provided by Microsoft, full of telemetry.
bovermyer 6y ago
Tangentially related - Nova is a really solid modern alternative to VSCode and Sublime Text, as long as you're on macOS. Some of the extensions have some ornery bugs, but the ecosystem is young yet. The basic editor itself is really nice.
- Hamuko 6y ago
  I tried it out during the beta stage, but the search was really slow and the code formatting was very weird on Python. Haven't really bothered to test it again after.
umvi 6y ago
Seems like a bot auto closed it before an actual maintainer responded?
- brundolf 6y ago
  I didn't notice before but you're right, it was a bot that closed it/commented. So this could just be a runaway automation problem.
- pseudalopex 6y ago
  vscode-triage-bot commented between bpasero marking it out of scope and bpasero closing it.
DiabloD3 6y ago
So, everyone is discussing the merit of VSCode instead of the bug in question; given this, I, too, shall give my opinion: if I want an extensible, portable, good text editor that has a great community... I'm just going to use Vim. Hell, I even abandoned my 20 year old config just to go use SpaceVim because of how great the community is. 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.
- vikingcaffiene 6y ago
  I dunno man. Like you, I use vim for lighter text editing tasks and JetBrains stuff for times I need to get serious. Your comments make me think that maybe you haven't spent enough time with vscode to appreciate it though. I think for a lot of folks its a really good middle ground and I am pretty sure MS's long game on it is as a replacement for Visual Studio (that might be projection though. I've always hated that IDE...). 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!!) :)
  - DiabloD3 6y ago
    You're actually partly right: Microsoft has said they're going to replace the native VS editor with VSCode's editing element. VSCode as an editor seems to be a better editor than VS's editor, so clearly VS can only get better, but the answer isn't replacing VS with VSCode entirely.
gpm 6y ago
Not sure the claimed behavior counts as a memory leak? As long as it will re-use the allocated memory the next time it needs it, it seems fine to not free up memory allocated? That's how many programs work. For example many `Vector` implementations will never shrink even if you use less memory, many apps and even allocators will store freed objects in a cache for later re-allocation, etc.
- remify 6y ago
  This .. also it's an issue of V8, not electron or vscode.
juanbyrge 6y ago
I would have marked this closed as well. Memory leaks are notoriously hard to track down. Unless someone takes the first dive with a heap profiler, and provides some proof there's a leak, I'm closing the issue.
davidbanham 6y ago
Years ago I was shipping a language learning app for high school students. It was aggressively cross-platform across iOS, OSX, Android and Windows. We made a big effort to make as much of the code platform-agnostic as we could. 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.
belval 6y ago
While I understand that such issues are frustrating, I really wish people would stop using HN as somekind of Internet cannon to spam these issues. 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.

62 points by hajile 6y ago

symlinkk 6y ago

Probably because it’s an Electron issue, not a VSCode issue? How about we let them respond before freaking out

curmudgeon22 6y ago
Well, they closed the issue 21 days ago... if that’s the case, they could at least add a comment to that effect.
mellosouls 6y ago
Where have they indicated that it's an Electron bug when closing the issue? 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.

ogre_codes 6y ago

I've used it on and off for the past 14 months, but I have little love for it. I know VSCode is more or less the industry standard. But coming from Sublime Code, the performance of VSCode is pretty mediocre. On top of big memory demands, 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. 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)

candiddevmike 6y ago
What did you settle on for you vim plugin? ALE, coc?
- ogre_codes 6y ago
  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.
- ogre_codes 6y ago
  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.
0x6c6f6c 6y ago
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.
- ogre_codes 6y ago
  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 https://github.com/neoclide/coc.nvim
brundolf 6y ago
> 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.

brundolf 6y ago

The lack of a public explanation is bizarre, but surely there must be an explanation internally. Does anybody have any insight?

deleted 6y ago
[deleted]
nickelpro 6y ago
V8 having non-ideal memory compaction behavior for any given benchmark isn't something that the VS Code team has any amount of control over.
- brundolf 6y ago
  What makes you think that's the problem? And if it was, they could easily put a cap on this by telling people that's why it's out of scope
  - nickelpro 6y ago
    The memory usage doesn't grow indefinitely, it's not a leak. Opening a large file, closing it, then opening more smaller files doesn't cause further growth. If VS Code was holding onto old references from opening files: 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.
    - hajile 6y ago
      The original filer stated that an identical electron version on older builds didn't have the same issue. 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.

johnfn 6y ago

What? You expect the VSCode maintainers to write up a lengthy explanation for why they have to mark every one of their 100k closed issues as closed? Are we really ascribing malice because they didn't do that once? C'mon, can't we be above this sort of behavior?

basicneo 6y ago
+1. It's reasonable for projects with large backlogs to do a quick prune with lower quality, either via manually or via tooling. If something is particularly pressing, it will re-appear. It's not ideal, but neither is a large backlog.
hajile 6y ago
They didn't even ask for more details. They obviously didn't attempt to reproduce anything. They just closed the issue. The person who filed later noted that identical electron versions in earlier VS Code editions do not have the same problem. 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).

Scarbutt 6y ago

SublimeText's author single-handedly supported windows,macos and linux from the start, what was Microsoft's reason to choose electron? I have never used ST and Microsoft probably picked electron to capture the huge web development market and also provide a cloud IDE for it's cloud offerings, but it's worth noting that vscoded is touted as an "exemplar" electron app only because a big well funded team is doing thousand and thousands of micro-optimizations all the time full time.

ogre_codes 6y ago
Didn't they buy VSCode? Or Fork Atom early on or something? (Update D'oh they got Atom with Github long after VSCode)
- bovermyer 6y ago
  Microsoft initially added Intellisense to Atom and called it VSCode. It was not great, but better than Atom. 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.
  - brundolf 6y ago
    It's funny, because Electron was literally invented for Atom (note the wordplay!). I was a long-time holdout for Atom; I didn't want to ditch the original for the Microsoft takeover. But eventually I had no choice but to relent. Atom just got really sluggish once you had a few plugins running, and VSCode runs like a dream. 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.

HerbsMan 6y ago

Not sure why people using VSCode... it's big, slow and provided by Microsoft, full of telemetry.

bovermyer 6y ago

Tangentially related - Nova is a really solid modern alternative to VSCode and Sublime Text, as long as you're on macOS. Some of the extensions have some ornery bugs, but the ecosystem is young yet. The basic editor itself is really nice.

Hamuko 6y ago
I tried it out during the beta stage, but the search was really slow and the code formatting was very weird on Python. Haven't really bothered to test it again after.

umvi 6y ago

Seems like a bot auto closed it before an actual maintainer responded?

brundolf 6y ago
I didn't notice before but you're right, it was a bot that closed it/commented. So this could just be a runaway automation problem.
pseudalopex 6y ago
vscode-triage-bot commented between bpasero marking it out of scope and bpasero closing it.

DiabloD3 6y ago

So, everyone is discussing the merit of VSCode instead of the bug in question; given this, I, too, shall give my opinion: if I want an extensible, portable, good text editor that has a great community... I'm just going to use Vim. Hell, I even abandoned my 20 year old config just to go use SpaceVim because of how great the community is. 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.

vikingcaffiene 6y ago
I dunno man. Like you, I use vim for lighter text editing tasks and JetBrains stuff for times I need to get serious. Your comments make me think that maybe you haven't spent enough time with vscode to appreciate it though. I think for a lot of folks its a really good middle ground and I am pretty sure MS's long game on it is as a replacement for Visual Studio (that might be projection though. I've always hated that IDE...). 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!!) :)
- DiabloD3 6y ago
  You're actually partly right: Microsoft has said they're going to replace the native VS editor with VSCode's editing element. VSCode as an editor seems to be a better editor than VS's editor, so clearly VS can only get better, but the answer isn't replacing VS with VSCode entirely.

gpm 6y ago

Not sure the claimed behavior counts as a memory leak? As long as it will re-use the allocated memory the next time it needs it, it seems fine to not free up memory allocated? That's how many programs work. For example many `Vector` implementations will never shrink even if you use less memory, many apps and even allocators will store freed objects in a cache for later re-allocation, etc.

remify 6y ago
This .. also it's an issue of V8, not electron or vscode.

juanbyrge 6y ago

I would have marked this closed as well. Memory leaks are notoriously hard to track down. Unless someone takes the first dive with a heap profiler, and provides some proof there's a leak, I'm closing the issue.

davidbanham 6y ago

Years ago I was shipping a language learning app for high school students. It was aggressively cross-platform across iOS, OSX, Android and Windows. We made a big effort to make as much of the code platform-agnostic as we could. 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.

belval 6y ago

While I understand that such issues are frustrating, I really wish people would stop using HN as somekind of Internet cannon to spam these issues. 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.