How VSCode made bracket pair colorization faster (2021) • Hacker News Board

Re: How VSCode made bracket pair colorization faster (2021)

#61

Post by zwily » Thu, Jun 22, 2023, 4:07 PM UTC

Solvency wrote: post #15

voz_ wrote: post #8

If you can make something 10k x faster you didn’t so much fix it as just switch it to working correctly as it should have in the first place. VSCode is a good tool, but it’s unbearably slow, and it breaks my heart that so much development has converged on something written in electron with such a low regard for performance by any measure.

The craziest thing to me is the people who are conditioned into believing that it's not slow. I don't know if it's some sort of perverse Stockholm syndrome, or if young developers today are just not familiar with how incredibly fast desktop applications used to be decades ago. I regularly have to completely reboot it because it becomes so unbearably slow, input latency alone often reaches hundreds of milliseconds. An…

It's all about tradeoffs. I like the features I get from VSCode and find its ergonomics outweigh other editors enough that I choose it over them, even if it may not be as fast. Am I conditioned or stupid?

(I rarely have to restart it because input has lagged to hundreds of ms. Maybe if that happened regularly to me, I would feel the same as you.)

Re: How VSCode made bracket pair colorization faster (2021)

#62

Post by dimmke » Thu, Jun 22, 2023, 4:07 PM UTC

Solvency wrote: post #15

voz_ wrote: post #8

If you can make something 10k x faster you didn’t so much fix it as just switch it to working correctly as it should have in the first place. VSCode is a good tool, but it’s unbearably slow, and it breaks my heart that so much development has converged on something written in electron with such a low regard for performance by any measure.

The craziest thing to me is the people who are conditioned into believing that it's not slow. I don't know if it's some sort of perverse Stockholm syndrome, or if young developers today are just not familiar with how incredibly fast desktop applications used to be decades ago. I regularly have to completely reboot it because it becomes so unbearably slow, input latency alone often reaches hundreds of milliseconds. An…

Just curious - are you running some kind of debugger or profiling software through VSCode?

Because VSCode is very fast to me, and I experience literally no input latency at all. And I have used Electron based code editors that felt slow to me. Like, Atom always felt very slow to me.

This isn't a vehement defense of Microsoft or VSCode - I wish the industry had consolidated on something else, but it's the way things are right now. You don't have to use it, there are plenty of alternatives.

Re: How VSCode made bracket pair colorization faster (2021)

#63

Post by XCSme » Thu, Jun 22, 2023, 4:08 PM UTC

voz_ wrote: post #8

If you can make something 10k x faster you didn’t so much fix it as just switch it to working correctly as it should have in the first place. VSCode is a good tool, but it’s unbearably slow, and it breaks my heart that so much development has converged on something written in electron with such a low regard for performance by any measure.

Well, sometimes to make things 10k x faster you need to implement some really complex algorithms. Implementing a trivial solution doesn't mean that it was broken or wrong in the first place.

Imagine saying "machine learning" was broken because now it's 10k x faster to train using a dedicated TPU than a CPU, so we should have used TPUs from the start.

Re: How VSCode made bracket pair colorization faster (2021)

#64

Post by bamfly » Thu, Jun 22, 2023, 4:08 PM UTC

vbezhenar wrote: post #24

voz_ wrote: post #8

If you can make something 10k x faster you didn’t so much fix it as just switch it to working correctly as it should have in the first place. VSCode is a good tool, but it’s unbearably slow, and it breaks my heart that so much development has converged on something written in electron with such a low regard for performance by any measure.

That's surprising to hear, because I use vscode every day and its performance is miles away of any JS apps I've ever used. It truly feels like a native app when it comes to performance, at the same time keeping some "fluidity" of web app (like scale the entire UI with single key press or reloading the entire app like a web page). I'd say I never had issues with vscode performance and actually its performance is a maj…

It's better than other Electron programs (a low bar, since most of those perform shockingly poorly) but eats way more system resources and performs noticeably worse than Sublime Text, on my machine.

Re: How VSCode made bracket pair colorization faster (2021)

#65

Post by jve » Thu, Jun 22, 2023, 4:08 PM UTC

voz_ wrote: post #8

If you can make something 10k x faster you didn’t so much fix it as just switch it to working correctly as it should have in the first place. VSCode is a good tool, but it’s unbearably slow, and it breaks my heart that so much development has converged on something written in electron with such a low regard for performance by any measure.

> it’s unbearably slow

???

You probably have tons of extensions installed, right?

VSCode now features profiles - you can install extensions per, err, profile https://code.visualstudio.com/docs/editor/profiles

> If you can make something 10k x faster you didn’t so much fix it as just switch it to working correctly as it should have in the first place.

Read carefully. The extension API limited the extension performance - so they implemented it in core. It was not a builtin feature of VSCode before. From article:

>> VS Code's API and extension architecture was not designed to allow for high performance bracket pair colorization when hundreds of thousands of bracket pairs are involved...

>> While we would have loved to just improve the performance of the extension (which certainly would have required introducing more advanced APIs, optimized for high-performance scenarios), the asynchronous communication between the renderer and the extension-host severely limits how fast bracket pair colorization can be when implemented as an extension. This limit cannot be overcome...

>> Instead, in the 1.60 update, we reimplemented the extension in the core of VS Code and brought this time down to less than a millisecond - in this particular example, that is more than 10,000 times faster...

Re: How VSCode made bracket pair colorization faster (2021)

#66

Post by vbezhenar » Thu, Jun 22, 2023, 4:08 PM UTC

stewartmcgown wrote: post #38

vbezhenar wrote: post #24

Earlier quoted context omitted.

That's surprising to hear, because I use vscode every day and its performance is miles away of any JS apps I've ever used. It truly feels like a native app when it comes to performance, at the same time keeping some "fluidity" of web app (like scale the entire UI with single key press or reloading the entire app like a web page). I'd say I never had issues with vscode performance and actually its performance is a maj…

VSCode was essentially unusable for me on large projects. We're talking thousands of source files and god knows how many node_modules entries. Things like Go to Definition would regularly take 15+ seconds! Switched to WebStorm recently and have been very happy with the performance.

Today I worked with not-so-large project: 255 typescript files, 26K LoC, 920 modules in node_modules, 29351 js/ts files total (with node_modules), 4.5M LoC total. I just checked and go to definition works pretty much instantly.

Anyway go to definition is a function of LSP server, AFAIU. I understand that it's bundled with vscode and feels like a single product, but still I'd separate vscode and LSP servers and judge them differently.

Re: How VSCode made bracket pair colorization faster (2021)

#67

Post by taeric » Thu, Jun 22, 2023, 4:08 PM UTC

Odd to read that "While we would have loved to just improve the performance of the extension (which certainly would have required introducing more advanced APIs, optimized for high-performance scenarios), the asynchronous communication between the renderer and the extension-host severely limits how fast bracket pair colorization can be when implemented as an extension. This limit cannot be overcome." Especially when I try out "rainbow-delimiters" in emacs and see that it is already quite fast.

I can kind of buy into the idea that "async by default" is a good path to build plugins. It boggles my mind that some of these slownesses are just lived with, though. How many other plugins that haven't gotten the attention of the core team can never get sped up, because of this choice?

Re: How VSCode made bracket pair colorization faster (2021)

#68

Post by reaperducer » Thu, Jun 22, 2023, 4:09 PM UTC

voz_ wrote: post #8

If you can make something 10k x faster you didn’t so much fix it as just switch it to working correctly as it should have in the first place. VSCode is a good tool, but it’s unbearably slow, and it breaks my heart that so much development has converged on something written in electron with such a low regard for performance by any measure.

VSCode is a good tool, but it’s unbearably slow

The funny thing is that the reason I and many other people switched to VSCode is that it used to be so speedy.

I sometimes wonder how much of its decrease in speed over the last few years is due to feature bloat (which it seems to have in spades) and relying on hobbyists, who have less incentive to optimize, to fill out the plug-in ecosystem.

I moved my personal projects to Nova, and it's screamingly fast. But I still have to use VS for work, and even though I only have four plug-ins, the difference is like pouring water, versus pouring honey.

Re: How VSCode made bracket pair colorization faster (2021)

#69

Post by XCSme » Thu, Jun 22, 2023, 4:09 PM UTC

omazurov wrote: post #57

No mature, sensible code allows for 10x performance improvement (let alone...). Every time I see a statement like this I take it as a confession.

What if after a long research, you can change the complexity of an algorithm from O(N) to O(log N), which makes the code orders of magnitude faster on large datasets. Does it mean the original code was not "sensible code"?

Re: How VSCode made bracket pair colorization faster (2021)

#70

Post by arijun » Thu, Jun 22, 2023, 4:10 PM UTC

luckman212 wrote: post #53

tibordp wrote: post #25

Earlier quoted context omitted.

That's interesting, I don't find VSCode slow at all, even when working on large workspaces via SSH over a high latency link. Sure, there are native editors that are snappier, but not to the point that affect my productivity in any way. The one thing that VSCode does not handle well is large files (e.g. DB dumps, large JSONs, logfiles), but for coding, it really is not an issue.

What plugin are you using to open workspaces via SSH?

They are probably using "Remote - SSH" by the VSCode team. It was a big part of what convinced me to switch from Pycharm. That and being able to work on C++ code from the same tool.