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

101–110 of 247 posts

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

#101

Post by rizky05 »

sebzim4500 wrote: post #51
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…

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

[dead]

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

#102

Post by kayodelycaon »

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.

As a rather vocal user of Sublime Text 4, VS Code is an order of magnitude slower on basic UI interaction.

I eventually switched to VS Code but I miss immediate highlighting and extremely fast start times. It's very close to TextEdit launch speeds. VS Code crawls by comparison.

The only reason I'm using VS Code is the plugin system is way better.

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

#103

Post by seventhson »

david2ndaccount wrote: post #48
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.

> look, I'm sorry, but the rule is simple: > if you made something 2x faster, you might have done something smart > if you made something 100x faster, you definitely just stopped doing something stupid https://twitter.com/rygorous/status/1271296834439282690?lang... >

It might be stupid, or it also might just be naive, or a shift in priorities.

100x throughput improvement might just come from caching results from earlier computations (less naive) - at the cost of 10x memory footprint possibly (different priorities).

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

#104

Post by mrweasel »

sebzim4500 wrote: post #51
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…

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

Why is it that VSCode is the only good Electron app? I get that Microsoft have talented developers, but so does other companies, yet VSCode remain the single application that shows that Electron apps can work.

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

#105

Post by bemusedthrow75 »

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…

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 environment, it has made remote file searches actually useful, it's worthwhile to make use of language servers (even for PHP!), and it presents substantially the same UI wherever I work.

It is not noticeably interactively slow.

But if it was slightly slower than, say, TextMate or SublimeText, the cost of that interactive slowness would likely be more than offset by the sheer productive utility of the thing, and no longer needing to treat host, local VM and remote VM environments differently.

It is in sum enormously faster than anything else I've used.

But this is just the deranged ramblings of a kidnap victim?

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

#107

Post by dsab »

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 am working as embedded software developer and VSCode is extremaly fast compared to its first competitor - Eclipse.

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

#108

Post by flohofwoe »

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…

I switch between Visual Studio, Xcode and VSCode pretty much each day for C/C++ development, and out of those VSCode is by far the slickest to use (and also the most flexible). I'm also not exactly a newbie, having started to code in the mid-80s. I also tried out all the IntelliJ IDEs, and for those I cannot understand how people can put up with the UI sluggishness :)

Also: even Vim (which I often use for quick text editing tasks on the terminal) can get embarrassingly slow on large files if you start installing extensions.

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

#109

Post by paulddraper »

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 as fast as IntelliJ, Eclipse, PyCharm, Visual Studio.

(And anyone upset about Electron install sizes has clearly never used any of the above.)

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

#110

Post by bemusedthrow75 »

Shrezzing wrote: post #60
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.

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

They are indeed -- and it will avoid similarly costly stuff on anything you .gitignore.
Post reply on HN