Hacker News new | ask | show | jobs
by alexdima 2980 days ago
Hi, I'm a developer working on VS Code.

VS Code is architected in a way where extensions are not eagerly activated by default. Each extension can declare a list of activation events, such as e.g. opening a file of a certain language, invoking a specific command, starting debugging, etc. See for example the quite long list of activation events for our built-in TypeScript extension [1].

However, we also offer an activation event called ' * ', which means an extension can ask to be activated on startup. Some over-eager extensions might be using ' * ' to start up as soon as you open a VS Code window. You can find those extensions at any time using F1 > Developer: Show Running Extensions which will show the subset of extensions running at any time, and if they were activated on startup or not.

Moreover, that view can guide you into profiling the extension host and can help you easily figure out if any extension is consuming extensive CPU. This was added quite recently [2].

[1] https://github.com/Microsoft/vscode/blob/1638acdd62d94bc4d99...

[2] https://code.visualstudio.com/updates/v1_19#_running-extensi...

5 comments

VS code sometimes performs better than VS. Can you elaborate on the reasons? Are there plans to migrate some optimizations or architectural lessons to VS?
Not a VSCode developer, but I imagine VS and VSCode are so completely different under the hood that performances comparisons between the two are not very useful. Not only are they architecturally completely separate animals, but VS probably has a lot of legacy baggage that needs to stay for backwards compatibility, which VSCode lacks.
This is an amazing guide to find misbehaving extensions and thank you for your work on VS Code.
This is a great insight, thanks!

I wonder if there also is a place we can view the activation events of an extension from within VS code. If there isn't, I guess I can always find that info out from the hopefully available repository of the extensions.

Hovering over the activation time will show the reason the extension is active. e.g. "Activated because you opened a javascript file", "Activated on start-up", etc.
It could do the opposite too. When a loaded extension is not used for some time (maybe the user switched to an project with a different language), so there is no active code depending on it then it should unload it to free up resources.
F1 doesn't seem to work for me on macOS (could be my non-Apple keyboard), but I see that the command palette also gives access to Show Running Extensions - very cool!