loading...
Cover image for Keep VS Code from Becoming an IDE

Keep VS Code from Becoming an IDE

rpalo profile image Ryan Palo Updated on ใƒป3 min read

Some people like a big, heavy, comfy IDE. Some people like a light, zippy, relatively simple text editor and a terminal window. And some people like Emacs. We don't talk about them. (I'm joking, I'm sorry, I couldn't resist.) I'm part of the zippy editor/terminal group. This is a tip to help keep the VS Code editor lightweight like you've come to know and love.

I was using VS Code last week, and it was starting to feel really sluggish. It seemed like it was eating a lot of memory up (relatively) and I wasn't sure what was happening.

And then it hit me:

I Had Too Many Extensions Running

I love tools. Especially new shiny ones. I don't think I'm alone on this. Because of this, I frequently install new extensions just to try them out and kick the tires a little bit. I then promptly forget about them and leave them not only installed but also activated.

Each one of these extensions takes up memory, and uses battery, and slows you down. They can add time to startup speed, too. Keep in mind, my laptop isn't all that burly, and a new computer or more memory isn't in the cards for a little while, so every little bit of memory I can conserve is worth it.

Here's the Fix

Turn them all off.

You heard me.

Ok, maybe not all of them. But you don't need the entire Go-lang support system when you're working on a Ruby project, do you? You probably don't need all the Python support either. Or the C# snippets.

Go through each of your extensions in the extensions bar and disable them. You don't have to reload until you've done them all.

Disabling an extension

Now you are fast. You are sleek. You. Are. Speed.

Look at all those disabled extensions

OK, OK, Not All of Them

In my opinion, there are two kinds of extensions. The first are language support extensions. As I pick up a new language, I discover there's an extension that makes writing it better. Python, Go, Ruby, language-specific linting, prettifying, snippets, and intellisense.

Apparently, a good portion of these are set to only activate when you're working on a file with that particular language. (Thanks! @SirWindfield!)

Fyi, most of the language support extensions don't even get loaded if you work on a project that does not need them. VSCode uses events to activate extensions. All of the language support ones are registered for the file type event. Meaning that they only are loaded into memory and executed if you open a file or the file type they cover.
This means, if you work on a ruby project and have the python language support extensions activated, the only thing that is loaded is the manifest of that extension. It shouldn't add any noticable delay on startup since VSCode is only reading one file, package.json

However, some less well-behaved ones aren't set up this way. You can check when an extension is set to activate by looking in your extensions directory. On my system, it's at ~/.vscode/extensions/. You'll see a directory for each extension. If you look into an extension's package.json, you'll likely see a key for activationEvents. Well-behaved extensions will only activate on certain filetypes, commands, and terminal activities. Troublemakers will simply have an innocuous little "*". These are the ones you want to disable.

If this seems like too much work, just do what I do and disable all of these language-specific ones.

The other kind of extensions are the general developer happiness extensions. Things like journaling support, colored bracket matchers, Star Wars-based themes, and, of course, emoji support. Feel free to leave these enabled all the time. You deserve to be happy.

But What if I Want My Extensions?

Don't panic. If you go to work on a project that needs those language-specific ones, you can enable them just in your workspace.

Enabling within a workspace

Now you get the full power of your development environment, and your computer loves you.


Do you have some favorite extensions? Any that are a little obscure or don't get a lot of love? Let me know about them. I'm always looking for another extension to add to my list. I might even leave it enabled.


Originally posted on assert_not magic?

Edit 4/28/18: Updated some info on when extensions activate themselves, thanks to @SirWindfield.

Posted on by:

rpalo profile

Ryan Palo

@rpalo

Ryan is an engineer in the Sacramento Area with a focus in Python, Ruby, and Rust. Bash/Python Exercism mentor. Coding, physics, calculus, music, woodworking. Message me on DEV!

Discussion

markdown guide
 

Fyi, most of the language support extensions don't even get loaded if you work on a project that does not need them. VSCode uses events to activate extensions. All of the language support ones are registered for the file type event. Meaning that they only are loaded into memory and executed if you open a file or the file type they cover.
This means, if you work on a ruby project and have the python language support extensions activated, the only thing that is loaded is the manifest of that extension. It shouldn't add any noticable delay on startup since VSCode is only reading one file, package.json

 

Interesting. I feel like I remember reading about this, but I totally forgot about it. Iโ€™ll update the article in a minute, thanks for the info!

 

No problem :)
If you are interested into fast editors, keep an eye on x-ray, atoms successor ( probably). It uses a native server written in rust that handles all core functionality. They only use electron for the UI. Makes editing a blaze :) it's pre pre pre pre alpha though ^

Iโ€™ll bookmark it. Thanks!

 

There's also github.com/google/xi-editor Core is written in Rust, front ends in a variety of languages and platforms - one of which is Electron.

 
 
I'm part of the zippy editor/terminal group.

A Google search for zippy editor/terminal leads to Micro. Is this the thing you are part of?

 

No, but I've used it before. I'm just saying I tend to like using a separate, simple text editor and a terminal window. I don't tend to like large, powerful, all-in-one IDE's.

 

Oh I apologise for my mistake. Zippy is apparently an adjective. When you said that you were part of the zippy ide/terminal I thought it meant there is a minimalistic IDE out there called zippy and you are part of the group developing it so I curiously googled it. Haha!

Ooooh gotcha. Yep! Now I want to invent the Zippy Editor.

If it is gonna be an Electron app optimized to be minimal/efficient and not a command line tool I will join you on this endeavor.

 

Get off my lawn whippersnapper! VS Code is a lightweight editor? ๐Ÿค”

 

Itโ€™s at least as lightweight as atom or sublime text I suppose ๐Ÿ˜ฌ Definitely lighter than something like Eclipse. It depends on how many extensions you have running. Like any editor. But it opens up quick, can be configured down to a minimal, basic editing experience, and still allows for big power and productivity when you need it.

 

VS Code was much heavier on my laptop than sublime when I had a a 5400rpm HDD on it, even though I regularly disable/remove extensions per project as this article advises. No difference now that I installed an SSD though.

 

"It absolutely is"
-Anyone who's worked in an enterprise JAVA shop and forced to use Eclipse.

 

I work in an enterprise Java shop :) I'm not going to claim Eclipse is lightweight. (I'm not forced into Eclipse, I like it.) But an editor within an startup memory footprint close to our enterprise software's startup memory footprint is not something I would call lightweight either. VS Code does start up much faster than our enterprise software, or Eclipse for that matter.

 

Great article.๐Ÿ‘๐Ÿ‘Œ
I had the same performance issue today and before reading this article I have disabled some of the extensions and it is working like charm.

 

Thanks! You can also run the "Developer: Process Explorer" command (using cmd/ctrl+shift+p) and take a look at the extensionHost to confirm that's what's eating resources.

 

Didn't know that. Super helpful..

 

I've seen on your other post that you've tried Vim before, how could you go back and adapt to slow editors again, like VS Code?

 

Calling VS Code a slow editor seems like a bold choice. Keep in mind that speed is mainly a function of familiarity. I'm not 100% there with Vim -- I'm not even probably 20% there -- and so my progress and productivity are a bit slow. Sometimes I just need to bust something out and get it done, and, since I'm used to GUI's and clicking things, I can still get a lot done that way, fairly quickly.

While I'd love to do more things and be more productive in Vim, right now, I'm most productive in VS Code, especially for largeish projects.

 

That's fair! I mean you're right! I didn't mean to be that aggressive on that opinion... and it's really true that, once you're used to any editor of your choice, the compete result will come faster than if you've used another editor that you're not so comfortable...

My point was kinda about my own experience of having to wait for considerable seconds when opening large files or multiple files, and some delays when you try to use these modern editors VSCODE/Atom/Sublime with some features like linters etc...

I think that in the end, it's better to invest a little bit of time on vim in the beginning than having to deal with that delays from those editors for ... (I don't know how long)..

CheersโœŒ๏ธโœŒ๏ธ

Yeah, that makes sense. You can't beat the productivity and keyboardiness of Vim, especially for editing config files and small scripts and projects. I'll have to keep working at it to get good enough to do larger projects with it.

If you haven't tried VS Code in a while, consider giving it a go, as it's gotten significantly faster.

Thanks for the advice!

 
 

Nothing! Thatโ€™s why I said I was joking. ๐Ÿ˜ฌ Emacs has a reputation for being hard to learn and hard on the fingers, but with a very loyal fan base. Just poking fun. It works great for some people!

 

Thanks for the tip, although i don't have any issues in VS atm, this will help later on! :D

 

I actually use this that much, that I request a file to do it automagicly. You can read it here: github.com/Microsoft/vscode/issues...