How VSCode made bracket pair colorization faster (2021)(code.visualstudio.com) |
How VSCode made bracket pair colorization faster (2021)(code.visualstudio.com) |
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.
In my opinion it's in a comfortable "fast enough" position, and from the very beginning the VSCode team has shown a great dedication to having the best possible performance in the particular technology stack they have chosen. It's just equally true that they have chosen a technology stack that puts easy extensibility over performance.
Like, yeah. Neovim is faster and smaller than VSCode, by a lot on smaller hardware. And I'm pretty sure I could summon my experiences from 5 years ago or so of really putting effort into my vim setup to have many of the goodies of a modern IDE, like LSP support, search, highlighting and so forth. But sorry, if I do that, I'd have to spend like 8 hours to integrate a new language based on past experiences. Instead of just dumping an extension into a new derived profile in vscode and be done with it. And then we think about teammates who aren't as fluent in vim. Even if my Neovim/Vim setup might be faster or lower input latency at times, it won't give me that day of initial integration back, ever.
And honestly, if I think about slow editors, I think about old Eclipse builds. Maybe with bad plugins, bad Maven versions, or horribly customized to some embedded or enterprise or academic use case. Bonus points if used on shitty corporate hardware. That's a level of slow called "Looking up documentation in a browser ends up being faster than auto complete". Compared to those molochs, VScode is not slow at all if you look out a bit for plugin overload.
> It's silly to be bashing it as a "slow" Electron app when it's measurably way faster than XCode
One of my favorite mis-applications of opportunity cost from the perspective of developing features, and one I see constantly in market-brain types: the comparison is not on competing offerings but on whether the feature is present or not.
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'd say I never had issues with vscode performance and actually its performance is a major factor why I use it.
???
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...
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.
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.
> 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
100x throughput improvement might just come from caching results from earlier computations (less naive) - at the cost of 10x memory footprint possibly (different priorities).
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?
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.
Because VSCode is very fast to me, and I experience literally no input latency at all. And I have used Electron based code editors that felt slow to me. Like, Atom always felt very slow to me.
This isn't a vehement defense of Microsoft or VSCode - I wish the industry had consolidated on something else, but it's the way things are right now. You don't have to use it, there are plenty of alternatives.
Most of them have no idea how fast a computer is because they've been using ludicrously slow software for so long they just think that's normal. Microsoft developers these days seems to have a particularly warped understanding of what "fast" means in computing, see Teams startup times [0], VS startup times [1], or that whole debacle with Windows Terminal.
[0] https://twitter.com/i/status/1640972391265230848
[1] I couldn't find a video in a reasonable time frame, but it is very slow compared to its predecessors just to launch let alone do anything that might justify it.
I have very clear memories of desktop applications from decades ago, and how incredibly fast they were, and it's "not at all", because they were slow as heck.
... 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?
(I rarely have to restart it because input has lagged to hundreds of ms. Maybe if that happened regularly to me, I would feel the same as you.)
Are you still using that same computer from decades 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.
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.
I also use CLion, and it is quite slow for a few minutes after startup (though never as slow as VS), but then becomes fast as it finishes indexing or something.
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.
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.
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.
It had the promise of all the benefits of VS Code, but performance of a native app.
There’s a word for what you are trying to explain. The word is “fix”.
The exact same thing would have happened in a native editor if its plugin interface didn't anticipate a particular requirement.
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.
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.
VSCode as fast as IntelliJ, Eclipse, PyCharm, Visual Studio.
(And anyone upset about Electron install sizes has clearly never used any of the above.)
The speedup is from taking extension code built on a limited API and implementing it inside VSCode, using more information while doing so.
Chrome/Safari/Firefox extensions certainly don't have full access to everything the browser can do. Nor can IntelliJ plugins. Nor can... practically any other implementation of extensions.
https://github.com/microsoft/vscode is available if a developer wanted to contribute something to core, anyway.
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?
Aside from that, the algorithm they described is one an undergrad could come up with. Pure vanity blogpost here.
already submitted two years ago (268 comments)
Making bracket pair colorization faster - https://news.ycombinator.com/item?id=28692470 - Sept 2021 (265 comments)
When everything is colorful, nothing stands out.
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
For slightly more control, you can also use alt+shift+right (or left) to expand/contract your selection to the matching bracket.
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.
Just installing the proper LSP for the language you work in makes a world of difference.
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 the "normal" version, see your eye doc...
It isn't a complete replacement for bracket colorization, but it helps in a lot of cases.
(Not colorblind, I just prefer a grey scale theme for my indent reminders!)
Given that colour blindness is a wide spectrum, I don't know what more people expect VS Code to do here?
Your chosen theme decides the original colours, then you can override them. Isn't that enough?
"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.
The VSCode team took it out of that environment completely, which opened up a huge number of optimization possibilities.
Just keep everything slow and then everything will be alright.
"I'm sending in more trains!" [0]
Only the trains are additional layers of abstraction and the accompanying bloat.
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.
Personally it feels just as fast or faster than before. Especially with things like the mentioned bracket colorizer beinf built in compared to the extension I was previously using.
That was a few years ago now and I've since moved away due to its performance issues, though ironically I then found myself switching again to Emacs which is definitely slower than VSC
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.
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.
When I first started my current job, they gave me a laptop that was under specced due to the high performance laptops being back ordered.
Vscode performed really poorly, but so did everything else. MS teams was the worst offender by far. I had to close every other application in order to join a meeting, lol
Who knew that having 100% CPU and 100% ram usage would slow applications down...
I am not.
But I wouldn’t seek to patronise them either, or describe their thinking as “perverse”.
Some other editors are consistently fast, for everyone, always (like [n]vim). Not because they're special but editing text just isn't that big a deal and these editors don't try to do too much graphically, so their performance is great.
Another problem is the combination of extensions probably has a significant impact on performance and resource usage. So person A uses it to edit JavaScript and has no problem, but person B uses it to edit Ruby and has one. It might not even be VS Code's fault, maybe an extension, but it is seen as if it's the editor since it's a whole package and the input latency is what's suffering.
My two cents, I've never seen a case of "VSC is slow" that isn't user error in this vein or on codebases that don't struggle similarly with similar tools. Ex, if clangd is struggling with your million file codebase under VSC it doesn't somehow become more responsive under Neovim.
And ya, anecdotally, I've never seen input latency specifically move an inch. The VSC team lives and dies on input latency and it shows in the current product.
Doesn't really work (in my experience) in the real world...
That being said I'm a huge fan of prioritizing longevity of computer parts versus constantly upgrading and generating e-waste.
I’ve since upgraded to a 2014 i7 and now VS Code feels fast.
I understand that everyone's situation is different, but I live in a poor country, making like $2k/month and still consider investments into my computer worthwhile, so I never tried to save money on it. This is american website, so most people here surely can afford fast computer for their work.
Also, I don't understand at all what your last sentence there means.
However, it has something that I find superior: when you're on a bracket, it will highlight its opposing bracket (closing if you're on opening, and vice versa).
The reason I think it's superior is that you can see directly which specific bracket you're looking for, you don't have to hunt for the corresponding shade. And in case your brackets are unbalanced, you'll see it directly.
One where there is finite time and resources and you have to pick and choose what you tackle. I could easily see this being ignored knowing that VSCode is so extensible and the community could easily pick up the missed non-core functionality until there was time to do it right.
Well, for me it IS helpful when the code block doesn't fit on single screen and I have to scroll AND there are multiple levels of brackets. Usually I try to put a cursor and not move it vertically and scroll to see where it ends. And coloring helps here.
Sometimes I want to understand - hey, where is the closing bracket, because there are 3 openings on single line, some expressions formatted on some lines, typecasts and whatnot that litters () around. Format document may not help there to align everything if I got any bracket missing there.
And I usually exit early, trying not to make too nested constructs, not using excess (), prefer constructs that eliminate brackets altogether. Anyways, not always we read our code. Of course python people can laugh that they don't even have such an issue, but others have, you know.
Maybe they'll port this feature to VS Code.
I tried it out, solves the problem you mentioned.
https://devblogs.microsoft.com/visualstudio/sticky-scroll-st...
(For examples of "to run faster," I'm talking of json and such. Calling out to the tree-sitter library is there, too. I'm not clear why that has to be native, oddly.)
I can certainly understand and agree with browsers having more locked down sections. For expert developer tools, though, it does feel a touch weirder.
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
}
Often happens to me when I run projects that output large CSVs, and it's a very notable performance impact.
Anyway go to definition is a function of LSP server, AFAIU. I understand that it's bundled with vscode and feels like a single product, but still I'd separate vscode and LSP servers and judge them differently.
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.
I also have 0 extensions installed :(
VS Code used to be my quick and dirty IDE when I didn't want to open something heavier, but it's gotten so much more painful than even a couple of years ago.
The featuresets aren't the same.
What are you thinking of, in terms of differences? I use both quite a bit (some of VSCode's plugins are better) and have always viewed them as very close to one another, in terms of features.
Sublime doesn't have any (real) debugger even with plugins. Some attempt to tack on a debugger but they have to do so via popup menus or overloaded "magical" text buffers and it's atrocious. Why can't I click on the line I want to break on? Why can't I see the stack in a nice editable tree? Right, because sublime is a text editor and VS Code is an IDE.
If VSCode can't handle four plug-ins, it isn't fit for purpose.
VS Code does that too and I think that's plenty to find matching brackets.
Never understood colored brackets either, it looks like a noisy rainbow to me. But I think it might depend on the language+theme combination you're using.
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.
Guess you've got a point, then, and I just don't use it that way.
In my experience, other IDEs have either a really high learning curve, needless bloat, or are closer to a notepad with extra features rather than a full fledged developing environment.
You can open VSCode and be welcomed by a lot of development features right on your face and wander through a lot of recommended add ons that add extra value out of the box. Also, since is electron based, multiplatform support is a no brainer.
Meanwhile, everyone is absolutely free to create a native VSCode clone. But that isn't happening at least for now. Maybe UI toolkits are a mess, maybe trying to mimic an UI in a 2D library is a PITA, maybe it's that an extensions engine needs to implement some "easier to develop" language (like javascript or Lua) and a full fledged interpreter for it, and it's so much work one would rather stick with Electron and be done with it.
Everyone hates VSCode, but nobody ever has managed to offer a competing alternative.
I think Nova[1] is generally angling for that spot on Mac. I really wanted to embrace it, and someday if I have a bunch of free time to indulge my curiosity I may well do. But…
> Everyone hates VSCode, but nobody ever has managed to offer a competing alternative.
This, plus even trying a new editor that isn’t a ~direct copy of a successful incumbent is a huge investment in time, energy, and delay/diversion of muscle memory.
I resisted VSCode for years, and skipped several others entirely, because I could half ass most of what I cared about with TextMate and the other tools I had at hand. When I finally caved on VSC, reconfiguring it and myself to be maximally productive took an enormous effort.
I’m getting old and I have shit to do. I’ll do it maybe one more time in my life, but only if something comes along with a new-value proposition on the order of what VSC brought me:
- actual semantic language awareness, which works everywhere
- incredibly flexible and accurate reference navigation, again everywhere
- commit history where I’m working, whenever I need it
- debugging that’s almost seamless with editing, regardless of what’s being debugged
- I hardly even care about extensibility because most of what I need is built in, but when I do need to look for an extension it’s almost always exactly what I want (doesn’t break flow, does well what it says on the tin, doesn’t come with a kitchen sink unless it’s supposed to)
- everything I’ve missed from previous editor preferences either has a built in config equivalent or a perfectly cromulent alternative
- bonus points to VSC team beyond these criteria: 9/10 times I install an update, some new feature addresses a problem I didn’t even know I could put in words
Maybe another round of that is possible, but I’m not holding my breath.
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 seen a tiny number that performed decently once running, but they are the exceptions.
This isn't the 1990s. My username alone should show I went through a period where the size of the binary and the memory size mattered.
These days with have gigabyte/terabyte hard drives and gigabytes of RAM. It generally sits unused and the O/S will handle reallocating if you really put the pressure on.
I'm not too concerned about VS Code hitting my RAM cap. Right now, with the entire front-end of a large enterprise application loaded, it's using 350 MB of RAM.
Meaningless in the grand scheme of things. And it's fast, on a 3 year old laptop.
And VSCode could be much, much worse. I tried AstroNvim on neovim for a while after it got some attention here. It consistently started up slower for me than VSCode does.
This time I used VSCode for nearly 2 months. Thought it's the end of an era, I'm not coming back to Sublime Text. I decided to push through and customize the configs just right for me, it was really becoming comfortable. Main reason why I wanted to switch is more active dev, more active extension community, and well integrated modern (some ML-backed) code writing and navigation tools.
I was wrong. After all the painstaking customization to bring it close to my ideal experience, while also getting used to things I didn't want to fight, I still had a bad time.
For one, the tab/cursor focus keeps going into weird places. I press a button, like ESC to switch to normal vim mode, and instead it does nothing, or something different, because turns out I'm not in the editor anymore. Keeps happening, maybe my own fault. The nifty AI tools integration is more of a nuisance — they jump in at bad times (with a delay), and their tab/enter functionality is weird, can never get it right. Most of my autocompletes have been unintentional. Maybe my own fault again, but felt super awkward. There is still no good vertical align plugin, despite such an active community (Sublime doesn't have one either, although they have one that gets me a bit closer). The language server stuff that worked badly in Sublime for my language also works badly in VSCode. The extensions, while numerous, are of questionable quality. I tried to stick to just a few well known ones.
After all the effort, I slowly came to realization that I'm back to not really using anything unique to VSCode, sacrificing more than I gained, being surrounded by lots of small moving details everywhere in the UI that make my experience more awkward than helpful, and occasionally getting my cursor stuck in weird parts of UI. I went back to Sublime.
For me, Neovim has always been faster than VS Code and that was before switching to Lazy plugin manager.
It was most likely some specific detail of my previous old piss-poor Windows work computer environment but the ad-hoc, whole project + all_java_dependencies + entire_jdk full file scanning on every single file opened (no matter if it was the same file opened) by the Visual Studio Code for Java Language Service (remember, it's Windows, so under molasses slow file access/reading) made everything extremely painfully slow for me in Visual Studio Code.
Granted, JetBrains IntelliJ took 50s+ to open the project in such bad environment but it didn't constantly rescan the whole thing every time another file was opened.
Things seems to have been improving a lot (Visual Studio Code for Java Language Service Lightweight Mode and JetBrains Fleet Lightweight Mode comes to mind) since that, but it is still the reason why I use those JetBrains IDEs at all.
The performance would have been pretty much the same if you used it like sublime text, so no plugins beyond synthax highlighting
And before someone claims that's not fair because sublime text has plugins too: no, it (to my knowledge) doesn't have any that enable the same classpath scanning vs code (and intellij or eclipse) does for java
It does perform better than IJ and the like, but that's a bit of damning with faint praise.
I don't comment beyond that on it as I don't use it more than I have to (for reasons unrelated to it being Electron-based) and want to avoid Speaking Of That I Know Not. I was speaking about Electron more generally.
C++ based editors like Kate blow both VSC and IJ out of the water. Runs so fast it feels janky, like the computer isn't doing anything.
And it offers vastly more features than VS Code.
Also, if you’re on a Mac — there’s an Apple Silicon build that is noticeably better.
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
I just wrote the exact same thing in another comment.
That's what the problem is ... it's the old timers complaining that things aren't native, thus they are RAM hogs and are slow by default. Even if they are fast, they are "slow and bloated" just because it's the gut reaction when you have layers on layers of other stuff over native code.
And I'm an old timer but I am not complaining. I love VS Code and I think it's blazing fast for what I need it for, a large Angular enterprise application.
Because you need to sink hundreds of thousands of man-hours into making it work.
And fight against web tech most of the time you're doing that.
99.9% of people who complain about electron apps are not ardent defenders of third world computing. It just violates their sensibilities.
But I think it’s unfair to hold developer tools back to 10 year old specifications.