Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Speeding up VSCode extensions in 2022

jason-williams.co.uk

Post reply on HN
Print view View original

31–40 of 40 posts

Re: Speeding up VSCode extensions in 2022

#31

Post by nmcela »

egg1 wrote: post #12

The more I read about VSCode and Electron apps in general, the more I'm convinced that all this effort is akin to putting lipstick on a pig. Modern CPU designs have all converged on multi-core as the solution to increasing performance, and yet on the software side of things... we've turned all of our desktop applications into Chrome instances running single-threaded event loops. That these extensions are even more po…

I have to say, I find it sad how even the most trivial apps, like some basic bug trackers, are built on top of electron and manage to be extremely slow even with the latest 4500€ hardware. And I have to use a bunch of different slow-as-hell apps like this in work. It is just embarassing.

Re: Speeding up VSCode extensions in 2022

#32

Post by dharmaturtle »

Tyriar wrote: post #25
eyelidlessness wrote: post #22

Earlier quoted context omitted.

It would be utterly shocking to me if VSCode isn’t using several worker threads for LSP, extensions, etc.

VS Code team member here. The diagram in the article is a little wrong, but the basics of it are: - The "main process" which manages the windows (renderer processes) - The renderer process" contains the UI thread for each window, the renderer process can have its own worker threads - The extension host loads extensions in proc, extensions are free to create their own threads/processes. The separate process for extens…

Off topic: Is there a document/blog/article somewhere about the plugin architecture of VS Code? I'm less interested in developing a plugin (which google results usually yield) and more interested in, say, how VS Code determines the order in which plugins are called.

Re: Speeding up VSCode extensions in 2022

#33

Post by Tyriar »

dharmaturtle wrote: post #32
Tyriar wrote: post #25

Earlier quoted context omitted.

VS Code team member here. The diagram in the article is a little wrong, but the basics of it are: - The "main process" which manages the windows (renderer processes) - The renderer process" contains the UI thread for each window, the renderer process can have its own worker threads - The extension host loads extensions in proc, extensions are free to create their own threads/processes. The separate process for extens…

Off topic: Is there a document/blog/article somewhere about the plugin architecture of VS Code? I'm less interested in developing a plugin (which google results usually yield) and more interested in, say, how VS Code determines the order in which plugins are called.

You could look up activation events on the website, I don't think we guarantee anything relating to order other than that. Generally the order in which they're activated shouldn't matter in practice.

Re: Speeding up VSCode extensions in 2022

#34

Post by Madeindjs »

egg1 wrote: post #12

The more I read about VSCode and Electron apps in general, the more I'm convinced that all this effort is akin to putting lipstick on a pig. Modern CPU designs have all converged on multi-core as the solution to increasing performance, and yet on the software side of things... we've turned all of our desktop applications into Chrome instances running single-threaded event loops. That these extensions are even more po…

JavaScript now include workers and with Node.js have Worker threads. I am pretty sure that MS guys use it into VSC.

Re: Speeding up VSCode extensions in 2022

#36

Post by wonnage »

egg1 wrote: post #12

The more I read about VSCode and Electron apps in general, the more I'm convinced that all this effort is akin to putting lipstick on a pig. Modern CPU designs have all converged on multi-core as the solution to increasing performance, and yet on the software side of things... we've turned all of our desktop applications into Chrome instances running single-threaded event loops. That these extensions are even more po…

Multithreading isn't some magic thing you slap on to go faster. You'll find single-threaded event loops in all sorts of high-performance code, e.g game engines.

Re: Speeding up VSCode extensions in 2022

#38

Post by vlovich123 »

wonnage wrote: post #36
egg1 wrote: post #12

The more I read about VSCode and Electron apps in general, the more I'm convinced that all this effort is akin to putting lipstick on a pig. Modern CPU designs have all converged on multi-core as the solution to increasing performance, and yet on the software side of things... we've turned all of our desktop applications into Chrome instances running single-threaded event loops. That these extensions are even more po…

Multithreading isn't some magic thing you slap on to go faster. You'll find single-threaded event loops in all sorts of high-performance code, e.g game engines.

Which high performance game engine is single threaded? To my knowledge they're all multithreaded and heavily pipelined.

Re: Speeding up VSCode extensions in 2022

#40

Post by coldtea »

vlovich123 wrote: post #38
wonnage wrote: post #36

Earlier quoted context omitted.

Multithreading isn't some magic thing you slap on to go faster. You'll find single-threaded event loops in all sorts of high-performance code, e.g game engines.

Which high performance game engine is single threaded? To my knowledge they're all multithreaded and heavily pipelined.

Parents wrote about the game engine event loop. Not the engine in general.

VS Code is not single-threaded in general. It's event-loop is.

Post reply on HN