VS Code - How many extensions should I use?

#vscode #performance

VS Code is a relatively lightweight editor with a core set of features. It is up to the user to extend the editor to their particular needs through extensions. In fact, many core features are written as extensions. You can see the builtin extensions by searching with @builtin in the extensions sidebar.

People have contrasting attitudes to extensions. Some people have a long list of extensions they use and rhapsodize about "must-use" extensions. Other people refrain from using many extensions because they want to avoid "bloat". Other people might be somewhere between these 2 attitudes. Other people will tell you to use Vim! 😉

The thing is you don't need to belong to a particular camp. If you understand a bit more about VS Code, you can be more pragmatic, and do what suits you.

Central to this is the recognition that at one time, only a portion of your extensions are loaded. As you can see in the previous screenshot, extensions such as CSS Language Features and Emmet are builtin to VS Code, would you expect them to be loaded always?

I wouldn't, and they aren't! We will explain more on this in the next section.

Also, you should recognise what your perceived performance of VS Code is. It is based on the initial time it takes to load the editor and become active, and how long it takes you to do certain actions. This is affected by what extensions are loaded for your typical project, when they are loaded, and if they are well behaved (well written).

I will show you how you can see what extensions are loaded, and how extensions affects performance generally. VS Code has added some visual cues to the UI to make this easier recently.

When are extensions loaded?

Extensions are conditionally loaded based on their Activation Events.

Some of the common activation events are:

* (Startup event): An extension is loaded when VS Code starts up. These extensions will always be active. This impacts the startup time of VS Code, so these should be reserved for critical extensions. You don't want a tonne of these, or the startup time will begin to suck!
onStartupFinished event: An extension is loaded sometime after VS Code starts up. This is like the * activation event, but it will not slow down VS Code's startup.
onLanguage event: The extension will be loaded whenever a file of a certain language is opened.

An extension can be loaded based on a collection of activation events. When the activation events are no longer met for an extension, the extension is unloaded.

To find out the activations events for an extension, you can look at the extension details in the extensions sidebar. They are shown on the "Feature Contributions" tab. It may be right at the bottom, as per screenshot below.

Generally, you will find that:

Critical and frequently used extensions are loaded on startup e.g. Git.
Language-specific extensions use the onLanguage event e.g. HTML Language Features, Emmet. If you have a HTML file open, then HTML Language Features and Emmet are loaded.
And more niche, less frequently used extensions tend to use the onCommand event more often e.g. Gulp support for VS Code.

You hope that the author of extension doesn't take liberties and always load their extension!

How do I check which extensions are loaded?

You can see a full list by running the command Developer: Show Running Extensions to get the basic stats about the running extensions.

You can also quickly see which extensions have been loaded in the extensions sidebar. If an extension was loaded, you will see a loading time next to its name (see yellow highlight). You can see in the screenshot below that the extensions, ESLint and Format Code Action, have been loaded for my project.

By clicking on the extension, you also see this info in the "Runtime Status" tab also (see second yellow highlight).

How do I review performance?

I think the best way to see where you are is to load VS Code without any extensions from the command-line with code my-project --disable-extensions, and then compare to open it with all your extensions code my-project. Open some files in your workspace to ensure you get a realistic impression.

Is there a big difference? If there is, review your extensions.

I wrote a more detailed article for FreeCodeCamp on this topic, VS Code Performance – How to Optimize Visual Studio Code and Choose the "Best" Extensions, you can give it a read if you want to know more.

My own investigation led me to remove a couple of extensions that had an activation event of * and that were not critical for me. I removed a couple of extensions with poor performance e.g. Live Server.

Also, keep in mind that extensions that are bundled can be much more performant, so favour extensions that are bundled. Suggest it to the maintainers of the extension if they are not doing this.

I took an the extra step of writing a few of my own extensions. I found Markdown All in One was quite slow. It loads in 263ms, and it has a lot of features that I don't use. So, I wrote 2 smaller extensions to meet my needs more specifically: Marky Edit and Marky Dynamic. They both load in approximately 5ms!

Conclusion

You shouldn’t be overly concerned with the number of extensions you have installed. This is the wrong way to think about it. The important thing is to recognize the impact an extension can have on initial startup time of VS Code, and how an extension behaves on a typical project for you. When you install an extension, do a quick review of the activation events of the extension, and see how it performs generally. You won’t go too far wrong if you do this habitually.