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

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

#51

Post by sebzim4500 » Thu, Jun 22, 2023, 4:04 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…

For the most part I agree with you but "miles away of any JS apps" is a low bar to cross.

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

#52

Post by chii » Thu, Jun 22, 2023, 4:04 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.

it's quite likely that your issue is with the actual node_modules directory being referenced as part of your source. It slows the LSP too.

Exclude it (via https://code.visualstudio.com/docs/getstarted/settings) by using

  "files.exclude": {
    "**/.git": true,
    "**/.svn": true,
    "**/.hg": true,
    "**/CVS": true,
    "**/.DS_Store": true,
    "**/Thumbs.db": true,
    "**/node_modules" : true
  }

I've not had any issues with speed ever since i started excluding directories that contain junk stuff that you know you will not ever need to see in a project's view.

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

#53

Post by luckman212 » Thu, Jun 22, 2023, 4:04 PM UTC

tibordp wrote: post #25

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 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?

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

#54

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

sudosysgen wrote: post #21

iamgopal wrote: post #14

Earlier quoted context omitted.

What would be the possible solution ? Change size ? High contrast fg/Bg combinations ? Special UTF characters?

A different spectrum per type of colorblindness. It should work fine, unless you're completely blind to all colors, which is a very small proportion of colorblindness, most are only lacking perception of one out of three colors.

You can already do that: in the settings.json under workbench.colorCusomizations, change editorBracketHighlight.foregroundX where X is the level of bracketing you want to modify.

In practice, though, the reduced color vision combined with the small target that is a bracket (color vision degrades for smaller objects), means that this is of limited usefulness.

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

#55

Post by HL33tibCe7 » Thu, Jun 22, 2023, 4:05 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.

You're overlooking the fact that the reason that VSCode is good is precisely that electron enables a high development velocity.

Edit: also, if you read the article, you'll find that the 10k x performance increase is a comparison between the performance of a third-party extension and the performance once that extension has been rewritten and inlined into VSCode itself. It's not like they were being accidentally quadratic or something.

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

#56

Post by dmonitor » Thu, Jun 22, 2023, 4:05 PM UTC

pmarreck wrote: post #20

quietbritishjim wrote: post #7

Earlier quoted context omitted.

Seems like a fundamentally unsolvable problem. These techinques use a spectrum of colours for deeply nested brackets. (If you only have one or two levels of brackets then you don't need the colourisation in the first place.) But colourblind users fundamentally don't have that many choices of colours to pick from in the first place.

It's not unsolvable. Colorblind people are missing one axis of color (such as the red-green axis). It is perfectly mathematically possible to pick colors that do not only differentiate along this axis, hence this option in many AAA games. Here's an online simulator to see what colorblind people of various types see. Note that if you yourself try this and the colors for one of the examples don't seem to change from th…

just the ability to change the bracket colors with reasonable default selections for colorblindness seems like a more than reasonable request

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

#57

Post by omazurov » Thu, Jun 22, 2023, 4:05 PM UTC

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.

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

#58

Post by fragmede » Thu, Jun 22, 2023, 4:05 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…

What CPU do you have? Because even though VSCode is "just" a text editor, I've found it's relatively demanding. A Core 2 Duo, which is admittedly a little old, but which does absolutely fine with vim, is slow to the point of being unusable with VSCode.

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

#59

Post by lkbm » Thu, Jun 22, 2023, 4:05 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.

I switched from Pycharm to VSCode because on my 2015 MBP, Pycharm was too sluggish. (Mostly a memory hog, I think.) Now that I'm on an M1 Max, vscode feels completely unconstrained, and I suspect Pycharm would as well.

Though, to be fair, I did actually run into an actual "borderline-frozen" situation yesterday doing a regex search that matched a bunch of very long lines in a log file.

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

#60

Post by Shrezzing » Thu, Jun 22, 2023, 4:06 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.

>We're talking thousands of source files and god knows how many node_modules entries.

I think most VSCode features are disabled for node_modules directories by default.

At a guess, I'd say re-disabling that in your workspace file would resolve all of your performance issues. For even simple projects you'd be including hundreds of MB of text files, and thousands of subdirectories.