[code-blooded]

To be devil's advocate (despite being a long vim user): Lapce has a GUI, so they are not in the exact same category. Having lightening fast GUI is still a novelty, because the most popular IDEs like VSCode or JetBrains IDEs have slow downs from time to time.

[corethree]

It's not the GUI itself. A console application in a window is still a gui rendering console text. It's the fact that Vscode and jetbrains use a high level language/engine that makes it slow.

For jetbrains it's java and for vscode it's an html rendering engine. An IDE built from vulkan or some other low level graphics API can likely be even faster then vim depending on the console it's running within.

[hnlmorg]

The IDE is only going to be as fast as the slowest LSP service you’re using.

[schemescape]

I would assume that LSPs are queried asynchronously. That's at least how it appears in VS Code.

[hnlmorg]

Asynchronous code doesn’t make something fast. It just prevents the application hanging when waiting for a function to return. But if that function is user facing (eg values for a context menu) and is slow, then your application is still going to feel slow in spite of those functions be asynchronous.

Coincidentally this is actually a problem I faced when writing my alternative shell.

[schemescape]

Right, I just meant it wouldn’t hang the UI (as the parent comment seemed to imply).

[hnlmorg]

That wasn’t what I was implying.

I was just saying that you can make the text editor as lightning fast as you want but the moment you need to do anything useful with an IDE you become dependent on the performance of your plugins.

This is why I’m a little jaded when people talk about IDE performance. Unless that IDE is using its own bespoke plugins, and the trend these days is (thankfully) moving away from that, it’s really not a good benchmark any longer.