Live data from Hacker News

How VSCode made bracket pair colorization faster (2021)

code.visualstudio.com

81–90 of 247 posts

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

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

What is faster than vscode? I've tried emacs and intellij and both have slow start up, break up and cause issues more often

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

#82

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…

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.

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

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

There is a Microsoft-built plugin called Remote - SSH, which fits into a group called "Remote Development" that includes WSL and Docker versions. It basically runs most of vscode on the remote, and feels just as fast as local on a decent connection. Most of the heavy lifting is done on the remote so things like full project searches, or linting, etc not having to go through ssh to access the files.

I use it for almost all of my development. I launch an ec2 instance with my projects and all of my code and data stays in my dev vpc. I can connect from my laptop or workstation and I can spin up extra dev environments if I am working on multiple projects. Plus, since the projects usually involve a pretty big data set, i don't have to download that locally and it can be replicated quickly within the vpc for each dev environment.

The SSH extension even knows how to forward ports back and you can add/remove port forwards from the vscode ui.

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

#84

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.

Live share is an amazing thing that Microsoft demos.

Doesn't really work (in my experience) in the real world...

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

#85
post #81
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.

What is faster than vscode? I've tried emacs and intellij and both have slow start up, break up and cause issues more often

sublime is faster from a text editing perspective. less cursor latency, scroll latency, render latency etc. it is significantly faster, like going from 60hz to 120hz.

that being said i use vscode due to the remote ssh stuff which is pretty handy. took me a while to get used to the latency everywhere.

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

#86
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 XCode. The difference in responsiveness is night and day. Before VSCode, I would almost exclusively just use Vim. It's silly to be bashing it as a "slow" Electron app when it's measurably way faster than XCode, a native IDE developed by a company with an integration advantage of being in control the underlying OS and hardware.

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

#88
post #17
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 not the fastest IDE out there, but it's certainly not unbearably slow.

I wish people criticising vscode's slowness would give faster options. It can't be any Jetbrains ide because I've used them all and they can be slow as hell, and buggy especially when pulling new changes. No wonder they are playing catch up with vscode with their fleet ide.

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

#89
post #80

Earlier quoted context omitted.

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

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.

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

#90

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…

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.

[dead]
Post reply on HN