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

How VSCode made bracket pair colorization faster (2021)

code.visualstudio.com

Post reply on HN
Print view View original

121–130 of 247 posts

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

#121

Post by Barrin92 »

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.

compared to what? VsCode is slower than vim without plugins, but it's not slower than anything that has feature parity. VsCode is closer in functionality to an IDE than it is to a text editor, and in that context it is very snappy.

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

#122

Post by compiler-guy »

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.

The code was both mature and sensible _within the limits of the environment and API available to it_.

The VSCode team took it out of that environment completely, which opened up a huge number of optimization possibilities.

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

#124

Post by SketchySeaBeast »

uoaei wrote: post #111
bilalq wrote: post #86

Earlier quoted context omitted.

I disagree with all points here. The speed performance became possible by being able to implement this within VSCode's core rather than over the extensions API. Without proving the value proposition as an extension first, it'd be difficult to get a change like this merged into core at the start. Also, VSCode is by far the fastest IDE I've ever used. I occasionally need to interact with IntelliJ, Android Studio, and X…

In what world would it be needed to prove the value proposition of "users can see which open brackets are associated with which close brackets"? Thus just seems blindingly obvious to me and probably anyone who's spent more than 40 hours writing code. > It's silly to be bashing it as a "slow" Electron app when it's measurably way faster than XCode One of my favorite mis-applications of opportunity cost from the perspe…

> In what world would it be needed to prove the value proposition of "users can see which open brackets are associated with which close brackets"?

One where there is finite time and resources and you have to pick and choose what you tackle. I could easily see this being ignored knowing that VSCode is so extensible and the community could easily pick up the missed non-core functionality until there was time to do it right.

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

#125

Post by geodel »

paulddraper wrote: post #114
bilalq wrote: post #86

Earlier quoted context omitted.

I disagree with all points here. The speed performance became possible by being able to implement this within VSCode's core rather than over the extensions API. Without proving the value proposition as an extension first, it'd be difficult to get a change like this merged into core at the start. Also, VSCode is by far the fastest IDE I've ever used. I occasionally need to interact with IntelliJ, Android Studio, and X…

You don't understand. Electron = slow and big install Even if other tools are objectively slower and bloatier, it is a immutable law that Electron = slow and big install

I think people are needlessly disparaging this beautiful, fast, lightweight tool.

These look similar to haters who claimed horse cart can't be faster than automobile once some performance optimizations are put in place.

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

#126

Post by dlisboa »

edgyquant wrote: post #32
Solvency wrote: post #15

Earlier quoted context omitted.

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…

I’ve no idea what you’re on about, and I come from CLI editors (vim.) VSCode is not slow at all for me, no latency I can readily see. My only complaint is that LiveShare is incredibly buggy and my team does a ton of pair programming.

I think that's part of the issue that polarizes people: it's not consistently slow and it's not consistently fast. So you get people who can't understand how it's usable, and others who can't understand how anyone has a problem with it.

Some other editors are consistently fast, for everyone, always (like [n]vim). Not because they're special but editing text just isn't that big a deal and these editors don't try to do too much graphically, so their performance is great.

Another problem is the combination of extensions probably has a significant impact on performance and resource usage. So person A uses it to edit JavaScript and has no problem, but person B uses it to edit Ruby and has one. It might not even be VS Code's fault, maybe an extension, but it is seen as if it's the editor since it's a whole package and the input latency is what's suffering.

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

#127

Post by bilalq »

uoaei wrote: post #111
bilalq wrote: post #86

Earlier quoted context omitted.

I disagree with all points here. The speed performance became possible by being able to implement this within VSCode's core rather than over the extensions API. Without proving the value proposition as an extension first, it'd be difficult to get a change like this merged into core at the start. Also, VSCode is by far the fastest IDE I've ever used. I occasionally need to interact with IntelliJ, Android Studio, and X…

In what world would it be needed to prove the value proposition of "users can see which open brackets are associated with which close brackets"? Thus just seems blindingly obvious to me and probably anyone who's spent more than 40 hours writing code. > It's silly to be bashing it as a "slow" Electron app when it's measurably way faster than XCode One of my favorite mis-applications of opportunity cost from the perspe…

Maybe blindingly obvious in hind-sight, but none of the IDEs I mentioned in my last comment have this feature. Nor does any other IDE I've ever used. It's not hard to imagine why a novel feature, without much prior art, potentially sitting on the blocking path for UI rendering, and contributed by an external person would face friction in being merged into core. Not to mention the onboarding complexity of making a change like this in core vs as a standalone extension for a new contributor.

Also, I don't understand at all what your last sentence there means.

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

#128

Post by dang »

peoplefromibiza wrote: post #3

2021 already submitted two years ago (268 comments) https://news.ycombinator.com/item?id=28692470

Thanks! Macroexpanded:

Making bracket pair colorization faster - https://news.ycombinator.com/item?id=28692470 - Sept 2021 (265 comments)

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

#129

Post by wongarsu »

bilalq wrote: post #86
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.

I disagree with all points here. The speed performance became possible by being able to implement this within VSCode's core rather than over the extensions API. Without proving the value proposition as an extension first, it'd be difficult to get a change like this merged into core at the start. Also, VSCode is by far the fastest IDE I've ever used. I occasionally need to interact with IntelliJ, Android Studio, and X…

Compared to Sublime Text VSCode is sluggish and hilariously bad at handling large files. Compared to Android Studio, VSCode is lean and very fast.

In my opinion it's in a comfortable "fast enough" position, and from the very beginning the VSCode team has shown a great dedication to having the best possible performance in the particular technology stack they have chosen. It's just equally true that they have chosen a technology stack that puts easy extensibility over performance.

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

#130

Post by KnobbleMcKnees »

voz_ wrote: post #116
bilalq wrote: post #86

Earlier quoted context omitted.

I disagree with all points here. The speed performance became possible by being able to implement this within VSCode's core rather than over the extensions API. Without proving the value proposition as an extension first, it'd be difficult to get a change like this merged into core at the start. Also, VSCode is by far the fastest IDE I've ever used. I occasionally need to interact with IntelliJ, Android Studio, and X…

Comparing with Xcode is a joke.

Point stands about bashing electron for not being native, even if Xcode is a dumpster fire.
Post reply on HN