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

131–140 of 247 posts

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

#131

Post by NovemberWhiskey »

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…

>how incredibly fast desktop applications used to be decades ago.

... that'd be during the time period when WordStar 5.0 would have to load an overlay from the floppy drive (taking a few seconds at least) in order to, e.g. print, and the speed of spell checking was such that you could actually follow along as the checker scanned through your document?

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

#132

Post by bilalq »

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…

The extension already had a setting to tune the color palette even before it was merged into VSCode core.

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

#133

Post by wongarsu »

chii wrote: post #52
stewartmcgown wrote: post #38

Earlier quoted context omitted.

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 sin…

If you have large files (as in hundreds of MB or bigger) in your project directory, especially text files, it also really pays off to put them into either your .gitignore or the files.exclude.

Often happens to me when I run projects that output large CSVs, and it's a very notable performance impact.

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

#134

Post by practal »

When working on an experimental VSCode plugin recently, I noticed that bracket colorization was at odds with some basic functionality. For example, in comments, I didn't want colorized brackets, I just wanted everything in the same color. That wasn't possible, except for switching the native colorization off completely. Which I did.

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

#135

Post by [deleted] »

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

[deleted]

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

#136

Post by CalChris »

wenc wrote: post #82
fragmede wrote: post #58

Earlier quoted context omitted.

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.

I used to run vim and VS Code on a Core 2 Duo from 2005. Vim is a lot faster but VS Code is so much more powerful — it’s a full featured IDE. It’s not a quick and dirty text editor like Kate. It’s not meant to be that. I still use vim to edit config files but for everything else I use VS Code. I’ve since upgraded to a 2014 i7 and now VS Code feels fast.

I use VSCode NeoVim and clangd. This has gotten so good, although command mode took awhile, that I rarely need to use a terminal vim.

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

#137

Post by bemusedthrow75 »

bemusedthrow75 wrote: post #105
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…

So if I don't find it to be slow, I am not just wrong but delusional? VSCode with the Remote SSH mode has absolutely, objectively, sped up everything I do. It's easier to work on remote machines as if they were local, it hasn't ever seemed keystroke-slow (either on a 2015 Macbook Pro or a recent Core i3 thing -- a Surface Go 2 running Ubuntu). It has made it feasible for me to use integrated Git support in a remote e…

And FWIW, I wish I was a “young developer”!

I am not.

But I wouldn’t seek to patronise them either, or describe their thinking as “perverse”.

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

#138

Post by nickelpro »

pcl wrote: post #89
akkad33 wrote: post #80

Earlier quoted context omitted.

I use vs code and jet brains intellij. Vscode is by miles more stable and light weight for running a java spring app. Of course intellij runs a lot of stuff but the experience is not better for it. Intellij feels like a sloth next to vscode

Make sure you’ve got your IJ memory settings tuned right. I assign 8GB rather than the default (2?). Also, if you’re on a Mac — there’s an Apple Silicon build that is noticeably better.

> I assign 8GB rather than the default

This is not a good argument in a thread where the central claim is that VSC is a resource hog but other IDEs aren't

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

#139

Post by JohnFen »

geodel wrote: post #125
paulddraper wrote: post #114

Earlier quoted context omitted.

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.

I have literally never seen an Electron-based application that wasn't overly bloated and slow to start up.

I have seen a tiny number that performed decently once running, but they are the exceptions.

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

#140

Post by kaveet »

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…

This might be my own personal experience, but one effect of my colorblindness is that I place far less emphasis on color-coding in the real world--I'll subconciously ignore things like status indicators. When I think of alternative solutions here, I tend to reach for variables like font weight instead.
Post reply on HN