Hacker News Reader

Comment by fouc | Hacker News Reader

Is VS Code really that bad in CPU/memory usage?

Yes, it really is. I use VSCode as my daily driver because I can find an extension for anything. It's good for an electron app, but it's still an electron app. I just tried opening a 20mb log file with similar results on CPU usage. The memory usage for that one file was background noise compared to the 1.9GB VSCode was already using with 2 workspaces and 10 normal source files open.

I think the issue might be the number or type of plugins involved.

I work mostly with ASM, C, C#, and a bit of VB. Even with 3 separate folders open, intelligence running, a couple larger files (of order 100mb) open, ~20 tabs with source and CSV, and a few plugins to help readability, VSC is taking up "only" 700MB.

Not exactly sleek compared to old-school editors, but not quite as bloated as your example.

It's well worth noting that plugins like the C/C++ extension run separate instances for each relevant tab on every workspace. When you have many tabs and many plugins, it starts to eat up a significant amount of space.

Yes it is. https://github.com/jhallen/joes-sandbox/tree/master/editor-p...

As an Atom user I wanted to try this because historically Atom has been worse than VS Code at large files.

I don't have a 500k word text file laying around, but I tried an 80k line SQL script. FWIW, it's 8.5mb and the Atom wordcount plugin claims it's about 1.5 million "words".

Atom opened this file in 3-4 seconds and memory usage only increased about 30mb.

Navigation grinds to a halt with the wordcount plugin enabled. Once I disable its "always on" feature (normally it doesn't pay attention to .sql), navigation and editing seem snappy.

Just a data point. VS Code should be able to get much better...

Interesting that nano has low performance overall. It's easy to understand (it's not an advanced editor), but I really didn't expect it.

Also, notepad++ is all over the place.

Yes. Assuming you don't need to run other CPU/memory intensive programs, probably not a real big issue when plugged in, but it's a killer if you're running on battery.

Maybe not compared to other GUI apps, but when you've grown accustomed to the performance of vim in a terminal, it feels very sluggish in comparison

I run Emacs outside of the terminal and it's quite fast. There used to be a time where it was considered a resource hog but compared to the monster IDEs we have today it's pretty lightweight. It's not the best editor for dealing with huge files but it does the job (IIRC it used to be a significant limitation back in the 32bit days but not so much on 64bit systems).

I hear you. To be clear, I'm not saying vim is significantly faster than any other app out there. I'm merely saying VS Code specifically is sluggish in comparison

Maybe it was my configuration, but the reason I switched from vim to emacs, was that I was debugging some large log files that made vim choke. I read a comment praising that behavior and I was surprised to see that it was the case, more so as I was in the belief that emacs had a lot of bloat.

Which editor would you consider that is better with large files? Not really interested in switching, but really curious.

I genuinely don't know, I just noticed that Emacs could be rather sluggish for some operations while dealing with massive files. For all I know all other editors might fare worse.

Yes. Horribly so.

Reply on news.ycombinator.com