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 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.
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 major factor why I use it.
> 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.
Read carefully. The extension API limited the extension performance - so they implemented it in core. It was not a builtin feature of VSCode before. From article:
>> VS Code's API and extension architecture was not designed to allow for high performance bracket pair colorization when hundreds of thousands of bracket pairs are involved...
>> While we would have loved to just improve the performance of the extension (which certainly would have required introducing more advanced APIs, optimized for high-performance scenarios), the asynchronous communication between the renderer and the extension-host severely limits how fast bracket pair colorization can be when implemented as an extension. This limit cannot be overcome...
>> Instead, in the 1.60 update, we reimplemented the extension in the core of VS Code and brought this time down to less than a millisecond - in this particular example, that is more than 10,000 times faster...
> 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
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. And this is on a workstation that I use to render extremely sophisticated 3D animations.
The slowness that I've observed almost always comes from the language servers. The rest really isn't much worse, if at all, than something like emacs.
I do keep looking for lighter options, but have yet to find one that actually does all the things I want. Vim and emacs are okay, but getting the right plugins to get the right features I want is a pain. Other options seem to lack the ability to add those features at all.
I still use Jetbrains but I don’t really push it on other people the way I used to. It was always a pig, but it was less of a pig than Eclipse, which I haven’t met anyone who still uses it in a long time, so now Jetbrains is “the pig “.
I figured the targeted versions would fix that, but I haven’t found that to be the case, or at least not for mature projects.
Point is, VSCode isn’t trying to be good, it’s just trying to be better than Jetbrains. Which is a nearly universal failure mode in this industry, and why it takes us so long to get good tools. If someone throws a terrible tool out, we have to go through two or three generations of replacements before someone finally has an original idea that isn’t built on the misguided one we started with.
The bones for running other languages or enhanced Java on the JVM were laid down in Java 1.2, but the first assembler built for Java was terrible. It wasn’t even a macroassembler, you had to do your own pointer arithmetic for the stack and IIRC for the constant pool. It was two assemblers later before we got one that made me say, “this is actually pretty usable” and I don’t think it’s a coincidence that the number of JVM languages basically doubled a short time after that. We could have had all of this in 1998, not 2008.
VSC feels outright snappy compared to regular Visual Studio or Eclipse. Of course one can easily bog down VSC with a bunch of bad plugins, but i really can't complain.
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.
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.
The reason wasn't JS performance or Electron, but simply that bracket colorization was bolted on in an extension which had to make use of the existing extension API, which obviously didn't expose the needed internal features to properly implement bracket colorization.
The exact same thing would have happened in a native editor if its plugin interface didn't anticipate a particular requirement.
Software developers are conditioned to accept horribly slow interactions with their software due to compilers. Most compiled languages have zero regard for developer time with the lengthy compile times. The break in context and flow from those constant delays and the horrible hacks in tooling around trying to deal with it are a constant irritant that has taken root and just accepted.
> 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'm on a 3+ year old laptop writing enterprise Angular on it with numerous plugins and it's very fast.
I feel like your view may be impartial due to a dislike of Electron over native applications.
Well, sometimes to make things 10k x faster you need to implement some really complex algorithms. Implementing a trivial solution doesn't mean that it was broken or wrong in the first place.
Imagine saying "machine learning" was broken because now it's 10k x faster to train using a dedicated TPU than a CPU, so we should have used TPUs from the start.
The funny thing is that the reason I and many other people switched to VSCode is that it used to be so speedy.
I sometimes wonder how much of its decrease in speed over the last few years is due to feature bloat (which it seems to have in spades) and relying on hobbyists, who have less incentive to optimize, to fill out the plug-in ecosystem.
I moved my personal projects to Nova, and it's screamingly fast. But I still have to use VS for work, and even though I only have four plug-ins, the difference is like pouring water, versus pouring honey.
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.
Odd to read that "While we would have loved to just improve the performance of the extension (which certainly would have required introducing more advanced APIs, optimized for high-performance scenarios), the asynchronous communication between the renderer and the extension-host severely limits how fast bracket pair colorization can be when implemented as an extension. This limit cannot be overcome." Especially when I try out "rainbow-delimiters" in emacs and see that it is already quite fast.
I can kind of buy into the idea that "async by default" is a good path to build plugins. It boggles my mind that some of these slownesses are just lived with, though. How many other plugins that haven't gotten the attention of the core team can never get sped up, because of this choice?
Yeah, this was a very uninteresting article to me.
The real challenge would have been to make the extension architecture not terrible. That would have also had the nice side effect of enabling other extensions to become more performant.
Aside from that, the algorithm they described is one an undergrad could come up with. Pure vanity blogpost here.
I suspect that one of these days someone will just bite the bullet and write an abstract syntax tree editor, and eliminate at a stroke all of the "first, we turn the text into an abstract syntax tree" steps that occur in everything from code colourization through folding to code suggestions. (-:
One thing I miss the most from Xcode is the ability to double-click on any delimiter pair ([...], (...), <...>, {...}) to select all text between those delimiters.
I filed an issue against VSCode to get this implemented, but it never got enough upvotes..
Maybe posting about it here is my chance to get it done? :-P
Not quite what you're asking for, but you can click after the first bracket and then use the "Go to bracket" command to get roughly the same thing. You'll have to add a keybind for it though, there isn't one by default.
For slightly more control, you can also use alt+shift+right (or left) to expand/contract your selection to the matching bracket.
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.
Vscode like many text editors supports that kind of completion too, but you should seriously give a try to better completion engines such as GitHub Copilot or StarCoder.
I recently noticed, that code window scrolling is a bit smoother and faster with terminal window closed. Could this be one of those "10kx faster" opportunities?
The speedup is not the extension v1 to v2, it's extension v2 to implementing the feature in vscode. They talk a bit about how there's a fundamental limitation in the extension speed given the current (as of 2021) extension API.
And now make something more production oriented like multi-screen window support, whoops you can't and you buried this feature request in your github. GG.
And yet, somehow, no one has done anything to address the inherent issues for colorblind developers. All of these colorization add-ons are woefully inadequate in that regard.
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.
I mean, in this situation a big thing is taking a plugin and re-writing it as part of the core application. The initial plugin was inherently limited by the existing plugin API, which wasn't optimized for this specific use case.
"We improved a popular plugin by integrating it with our core application" doesn't feel like a confession to me. In fact, that's exactly what I'd like to see from an application developer. No application is perfect, and it's good when developers improve the basic look and feel of an application based on what their users want.
What if after a long research, you can change the complexity of an algorithm from O(N) to O(log N), which makes the code orders of magnitude faster on large datasets. Does it mean the original code was not "sensible code"?
I know reading the article is hard, but if you did you'd realize that it was slow because colorization was performed by an extension, and could not be optimized sufficiently because of limitations of the public API. They sped it up by moving it into the VS code core, which allowed it to take advantage of a bunch of features not available to extensions.
voz_|2 years ago
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.
bilalq|2 years ago
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.
vbezhenar|2 years ago
I'd say I never had issues with vscode performance and actually its performance is a major factor why I use it.
jve|2 years ago
???
You probably have tons of extensions installed, right?
VSCode now features profiles - you can install extensions per, err, profile https://code.visualstudio.com/docs/editor/profiles
> 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.
Read carefully. The extension API limited the extension performance - so they implemented it in core. It was not a builtin feature of VSCode before. From article:
>> VS Code's API and extension architecture was not designed to allow for high performance bracket pair colorization when hundreds of thousands of bracket pairs are involved...
>> While we would have loved to just improve the performance of the extension (which certainly would have required introducing more advanced APIs, optimized for high-performance scenarios), the asynchronous communication between the renderer and the extension-host severely limits how fast bracket pair colorization can be when implemented as an extension. This limit cannot be overcome...
>> Instead, in the 1.60 update, we reimplemented the extension in the core of VS Code and brought this time down to less than a millisecond - in this particular example, that is more than 10,000 times faster...
tibordp|2 years ago
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.
david2ndaccount|2 years ago
Solvency|2 years ago
zdragnar|2 years ago
I do keep looking for lighter options, but have yet to find one that actually does all the things I want. Vim and emacs are okay, but getting the right plugins to get the right features I want is a pain. Other options seem to lack the ability to add those features at all.
hinkley|2 years ago
I figured the targeted versions would fix that, but I haven’t found that to be the case, or at least not for mature projects.
Point is, VSCode isn’t trying to be good, it’s just trying to be better than Jetbrains. Which is a nearly universal failure mode in this industry, and why it takes us so long to get good tools. If someone throws a terrible tool out, we have to go through two or three generations of replacements before someone finally has an original idea that isn’t built on the misguided one we started with.
The bones for running other languages or enhanced Java on the JVM were laid down in Java 1.2, but the first assembler built for Java was terrible. It wasn’t even a macroassembler, you had to do your own pointer arithmetic for the stack and IIRC for the constant pool. It was two assemblers later before we got one that made me say, “this is actually pretty usable” and I don’t think it’s a coincidence that the number of JVM languages basically doubled a short time after that. We could have had all of this in 1998, not 2008.
KeplerBoy|2 years ago
HL33tibCe7|2 years ago
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.
lkbm|2 years ago
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.
noselasd|2 years ago
I've done almost all development in vim up till 3-4 years ago before switching to vscode. It's more than fast enough for me.
alberth|2 years ago
It had the promise of all the benefits of VS Code, but performance of a native app.
https://v2.onivim.io
theRealMe|2 years ago
There’s a word for what you are trying to explain. The word is “fix”.
ukFxqnLa2sBSBf6|2 years ago
flohofwoe|2 years ago
The exact same thing would have happened in a native editor if its plugin interface didn't anticipate a particular requirement.
eikenberry|2 years ago
EMM_386|2 years ago
I'm on a 3+ year old laptop writing enterprise Angular on it with numerous plugins and it's very fast.
I feel like your view may be impartial due to a dislike of Electron over native applications.
XCSme|2 years ago
Imagine saying "machine learning" was broken because now it's 10k x faster to train using a dedicated TPU than a CPU, so we should have used TPUs from the start.
paulddraper|2 years ago
VSCode as fast as IntelliJ, Eclipse, PyCharm, Visual Studio.
(And anyone upset about Electron install sizes has clearly never used any of the above.)
AnIdiotOnTheNet|2 years ago
dsab|2 years ago
unknown|2 years ago
[deleted]
unknown|2 years ago
[deleted]
ramraj07|2 years ago
reaperducer|2 years ago
The funny thing is that the reason I and many other people switched to VSCode is that it used to be so speedy.
I sometimes wonder how much of its decrease in speed over the last few years is due to feature bloat (which it seems to have in spades) and relying on hobbyists, who have less incentive to optimize, to fill out the plug-in ecosystem.
I moved my personal projects to Nova, and it's screamingly fast. But I still have to use VS for work, and even though I only have four plug-ins, the difference is like pouring water, versus pouring honey.
rusl1|2 years ago
Barrin92|2 years ago
dumdumchan|2 years ago
RektBoy|2 years ago
jaywalk|2 years ago
akkad33|2 years ago
tomcatfish|2 years ago
The speedup is from taking extension code built on a limited API and implementing it inside VSCode, using more information while doing so.
bluSCALE4|2 years ago
taeric|2 years ago
I can kind of buy into the idea that "async by default" is a good path to build plugins. It boggles my mind that some of these slownesses are just lived with, though. How many other plugins that haven't gotten the attention of the core team can never get sped up, because of this choice?
bagacrap|2 years ago
Aside from that, the algorithm they described is one an undergrad could come up with. Pure vanity blogpost here.
peoplefromibiza|2 years ago
already submitted two years ago (268 comments)
https://news.ycombinator.com/item?id=28692470
dang|2 years ago
Making bracket pair colorization faster - https://news.ycombinator.com/item?id=28692470 - Sept 2021 (265 comments)
Narishma|2 years ago
cubefox|2 years ago
kortex|2 years ago
yoyohello13|2 years ago
When everything is colorful, nothing stands out.
rochak|2 years ago
awestroke|2 years ago
sudoapps|2 years ago
JdeBP|2 years ago
tomtom1337|2 years ago
nielsbot|2 years ago
I filed an issue against VSCode to get this implemented, but it never got enough upvotes..
Maybe posting about it here is my chance to get it done? :-P
https://github.com/microsoft/vscode/issues/85587
jcparkyn|2 years ago
For slightly more control, you can also use alt+shift+right (or left) to expand/contract your selection to the matching bracket.
practal|2 years ago
jokoon|2 years ago
Sublime text also has a cheap way to do auto-completion, it will just look at existing words in the current file, it's often just enough.
speedgoose|2 years ago
butz|2 years ago
syngrog66|2 years ago
nephanth|2 years ago
rafaelturk|2 years ago
tiku|2 years ago
bick_nyers|2 years ago
robertoandred|2 years ago
dtagames|2 years ago
lkbm|2 years ago
Avlin67|2 years ago
RektBoy|2 years ago
frankreyes|2 years ago
arijun|2 years ago
steve76|2 years ago
[deleted]
Solvency|2 years ago
quietbritishjim|2 years ago
kortex|2 years ago
kaveet|2 years ago
omazurov|2 years ago
ARandumGuy|2 years ago
"We improved a popular plugin by integrating it with our core application" doesn't feel like a confession to me. In fact, that's exactly what I'd like to see from an application developer. No application is perfect, and it's good when developers improve the basic look and feel of an application based on what their users want.
XCSme|2 years ago
gopher_protocol|2 years ago
HL33tibCe7|2 years ago
compiler-guy|2 years ago
The VSCode team took it out of that environment completely, which opened up a huge number of optimization possibilities.
akasakahakada|2 years ago
Just keep everything slow and then everything will be alright.
https://news.ycombinator.com/item?id=36401488
ghnws|2 years ago