Hacker News Reader

Comment by egg1 | Hacker News Reader

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 poorly optimized is more icing on the cake.

View on HN

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.

Funnily enough the quote on textmate grammars in the article feels quite relevant:

>The fact that we now have these complex grammars that end up producing beautiful tokens is more of a testament to the amazing computing power available to us than to the design of the [TextMate] grammar semantics.

Amazing computing power available to them indeed.

It looks like VSCode is running many threads (some as separate processes) on my machine. Is what you're saying that it does not provide an API for extensions to schedule work on other threads?

Single threading is not the issue. Just 5% of single modern core should be plenty fast enough to run a text editor. You still want multiple threads of course, to avoid blocking the UI for background work, but computers are so fast nowadays that it should still be fast enough even if all threads were run on the same core.

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 extensions protects extensions from freezing the renderer

- Various other processes that live off either the main process or the "shared process", such as the pty host for terminals which enables the terminal reconnection feature when reloading a window (also file watcher, search process)

We've been shuffling where processes are launched from recently but the actual processes and their purpose probably won't change. You can view a process tree via Help > Open Process Explorer to help understand this better.

EDIT: Formatting

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.

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.

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

Reply on news.ycombinator.com