How VSCode made bracket pair colorization faster (2021)
code.visualstudio.comIf 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.
Compared to Sublime Text VSCode is sluggish and hilariously bad at handling large files. Compared to Android Studio, VSCode is lean and very fast.
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.
I switched away from sublime text because it only had a fraction of the features and extensions. Perhaps I'm just not using files large enough, most of our source modules top out at a few thousand lines of code.
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.
Just an anecdote for those curious about a specific experience.
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.
Compared to the others neovim should theoretically be snappier. Could it be bogged down by 3rd party plugins or something? If so try to switch to the lazy.nvim plugin manager which does a great job of lazy loading plugins, but more importantly allows you to profile the startup time and tweak loading mechanisms until you find a desirable balance between loading plugins and startuptime.
+1 for Lazy: https://github.com/folke/lazy.nvim
For me, Neovim has always been faster than VS Code and that was before switching to Lazy plugin manager.
Sublime Code isn't an IDE
"Sublime Code" isn't a thing at all.
By that measure neither is vscode. Both are extensible text editors with ide plugins available.
I guess I didn't realize Sublime has had LSP packages for a while now, though IIUC it still doesn't support it out of the box
Sublime Text in no way represents “average” native application. It doesn’t even use native GUI toolkits, ffs.
> Compared to Android Studio, VSCode is lean and very fast.
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 issue is that you tried to use vs code for Java. That plugin doesn't really work well, honestly.
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
Yeah, I'm a bit put off by the comments there.
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.
If you used VIM, there is no possibility VSCode would feel faster in any sense, I don't understand how it is possible. You can plug in the whole VSCode tooling inside VIM making it the same in terms of functionality, and it would not affect its startup time or input lag whatsoever - it will remain unnoticeable. It is possible to open infinite copies of vim recursively inside vim's own terminal, so even if I recursively stack up 32 vims with all my plug-ins loaded inside each other, they still don't show a hint of a lag
In what world would it be needed to prove the value proposition of "users can see which open brackets are associated with which close brackets"? Thus just seems blindingly obvious to me and probably anyone who's spent more than 40 hours writing code.
> 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.
Maybe blindingly obvious in hind-sight, but none of the IDEs I mentioned in my last comment have this feature. Nor does any other IDE I've ever used. It's not hard to imagine why a novel feature, without much prior art, potentially sitting on the blocking path for UI rendering, and contributed by an external person would face friction in being merged into core. Not to mention the onboarding complexity of making a change like this in core vs as a standalone extension for a new contributor.
Also, I don't understand at all what your last sentence there means.
It's always entertaining to me to see 'new'(ish) IDE features being lauded that have already been available in emacs for years, if not decades.
After a quick search through the settings, IntelliJ seems to indeed not have bracket colorization. I seem to remember there was an option for this, but it may have been a 3rd party plugin.
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.
> In what world would it be needed to prove the value proposition of "users can see which open brackets are associated with which close brackets"?
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.
> seems blindingly obvious
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.
> 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.
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...
Yes and: Make it work, then make it correct, then finally make it fast.
Comparing with Xcode is a joke.
Point stands about bashing electron for not being native, even if Xcode is a dumpster fire.
Is Xcode native app?
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
Even if that's true, there should be a reason, or a cause at least, that VSCode dominated over most IDEs out there.
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.
It's barely alpha, but lapce is kinda trying to be a native version of vscode.
> Meanwhile, everyone is absolutely free to create a native VSCode clone. But that isn't happening at least for now.
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.
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.
We're discussing one right now. VSCode is an electron-based application, isn't overly-bloated, and starts up quickly. I switch between IJ and VSC every day and VSC is significantly faster, including startup. But, even if it _was_ slower on startup, that would be a tradeoff I'd be happy with if it was faster or more functional normally. I restart my computer maybe once a week, I'd be fine to wait another couple seconds.
VSCode is better than many, but I do think it counts as bloated, has reasonably high recommended machine requirements, and performs more poorly than I would expect of such an application.
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.
To those who are missing it, the parent comment ^ is using sarcasm.
"Don't be snarky" is mentioned in the first rule of hn commenting. To be fair, I don't always abide by it either, but it's a good rule.
Yeah :/
> Electron = slow and big install
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.
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.
It's better than other Electron programs (a low bar, since most of those perform shockingly poorly) but eats way more system resources and performs noticeably worse than Sublime Text, on my machine.
Oh noes, who could’ve thought that application written in JavaScript that gets executed on browser engine is slower than lean C++ that uses their own custom GUI toolkit http://news.ycombinator.com/item?id=2822114.
Sublime text is an editor, VS Code is an IDE, though?
The featuresets aren't the same.
I'd say they compete in a similar space of smart plugin-friendly code editor, not IDE.
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.
For one thing VS Code has a full debugger with breakpoints and stack analysis that supports many backends out of the box, that's an IDE feature.
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.
Ah—I'd never noticed VSCode could do that, in years of using it. I ignore some of its features (some of which Sublime also has, and I tend to ignore them there, too) because I find them janky and fragile or requiring-configuration such that I lose a lot of time keeping them happy, like any kind of run-from-editor stuff and the built-in terminal (it always seems to have a messed-up environment or get itself into broken states) dropping to a separate terminal for that sort of thing. Not like when I'm, say, working in XCode or Intellij and almost exclusively run, build, & debug from inside the IDE, rarely touching a separate terminal.
Guess you've got a point, then, and I just don't use it that way.
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
IntelliJ is not very fast by any benchmark. I mean it's based on Swing! There's a pronounced multi-frame pause between right clicking and seeing a context menu.
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.
I haven't heard of Kate. I'll try it out
It's from the KDE project, and while it's portable, but I can't speak for how well it looks on other platforms.
It also does maybe a quarter of what IDEA can do. Let's see how it performs when it catches up to what IDEA does right now (maybe in another ten years).
It does everything I need to run to do my job. If intellij is doing more stuff that is slowing it down then maybe they can find a better performance-feature trade off by getting rid of the bloat
It would turn into another run of the mill text editor like VSCode then, and would lose most of its users.
Vs code is not a run of the mill editor though. It can be configured to support all useful features of intellij. Even then it's faster than intellij
Yeah this sounds like a misconfiguration. We've already forgotten that native apps tend to require a bit more fine control on how they use resources, all in the name of the cult of portability.
How do I configure it right? One good thing about vs code is it works well out of the box with almost zero custom configuration
IntelliJ has a lot of legacy code, including custom re-implementation of all things UI.
And it offers vastly more features than VS Code.
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
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.
Even though it is based on web tech and Electron, VSCode cares about performance, while garbage like Microsoft Teams does not. That's about it.
I use discord and gitkraken every day and I've never had any issues either. People just like to complain. They act as if using a few hundred megabytes for the main app you are using is an issue. It's not the 90s anymore ram is cheap, especially at those amount.
Why is it better to have a million people buy more RAM, creating a large amount of electronic waste and emissions, instead of putting some effort into not unnecessarily wasting resources?
You don't need to buy more ram. It was already cheap a decade ago. Ram has been in the multiple gigabyte range for longer than that. Having an app that you use all the time every day use a few hundred of the otherwise unused ram is perfectly reasonable.
> It's not the 90s anymore ram is cheap, especially at those amount.
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.
Or maybe you're just fine with throwing away thousands of dollars at it every few years, so you're not seeing the problem. The "solution" that most of the world simply cannot afford.
If I could roll my eyes any harder, they’d be spinning.
99.9% of people who complain about electron apps are not ardent defenders of third world computing. It just violates their sensibilities.
I am not one of those "99.9%" (seems like a random number pulled out of someone's ass). Most developers in my poor country don't make much and would quality as lower-middle class in yours. Including a good friend of mine, who is learning web development on a 10-year old laptop — he can't afford anything else. I know he struggles with VSC because I hear about it daily.
I feel for your friend, and I hope he gets some better hardware solutions soon.
But I think it’s unfair to hold developer tools back to 10 year old specifications.
Of cut it off with most of the world bullshit, we’re talking about development tool here, not solving world hunger.
There are no developers outside Silicon Valley, got it.
Right, because world is divided in Silicon Valley and third world hellholes.
People act as if their precious app is the only one a user is going to run and has the right to hog all the memory and CPU.
> Why is it that VSCode is the only good Electron app?
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.
Also, Figma.
I think WebAssembly might play a role there. https://twitter.com/mattrickard/status/1410714002456383490
Obsidian also
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 think unfortunately a CPU from 2008 just isn't gonna cut it here. Single thread benchmarks core for core have risen about 4x since then, average core counts have risen 4x, and L3 caches were added. Probably SIMD instructions are a consideration here as well.
That being said I'm a huge fan of prioritizing longevity of computer parts versus constantly upgrading and generating e-waste.
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.
Kate is not a "quick and dirty text editor" either? Kate has session and project support (admittedly a bit more clunky than VSCode, but it works), good LSP support, decent built-in search, GDB integration, a built-in terminal, Git integration, etc. Sure, it may be less polished than VSCode in some of these aspects, but they're there and mostly just work.
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.
I’ll bet a lot of this whole argument is just windows v mac. VS code is snappy on Mac, much less so on my windows machine.
Apple M1 Max.
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.
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
I've not had any issues with speed ever since i started excluding directories that contain junk stuff that you know you will not ever need to see in a project's view."files.exclude": { "**/.git": true, "**/.svn": true, "**/.hg": true, "**/CVS": true, "**/.DS_Store": true, "**/Thumbs.db": true, "**/node_modules" : true }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.
Today I worked with not-so-large project: 255 typescript files, 26K LoC, 920 modules in node_modules, 29351 js/ts files total (with node_modules), 4.5M LoC total. I just checked and go to definition works pretty much instantly.
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.
>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.
Weird, i often opened files with hundreds of thousands of code lines without any problem. We do have very modern Workstations at work though.
VS Code has stopped opening for me for certain codebases. And to be honest, these codebases aren't even that large.
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.
> it’s unbearably slow
???
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...
Thanks for mentioning profile support. For some reason I never thought to look into that, even though my own VSCode setup is definitely too cluttered.
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.
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.
Just the standard Remote-SSH
They are probably using "Remote - SSH" by the VSCode team. It was a big part of what convinced me to switch from Pycharm. That and being able to work on C++ code from the same tool.
<https://twitter.com/rygorous/status/1271296834439282690?lang...>> 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 stupidIt 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).
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.
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.
I think that's part of the issue that polarizes people: it's not consistently slow and it's not consistently fast. So you get people who can't understand how it's usable, and others who can't understand how anyone has a problem with it.
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.
Neovim isn't immune to slow plugins, it's just a smaller ecosystem and therefore has less exposure.
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.
Live share is an amazing thing that Microsoft demos.
Doesn't really work (in my experience) in the real world...
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?
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”.
This is a pretty condescending take, particularly for someone with such an extraordinary issue with VS Code. It is not that slow for the rest of us.
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.
Just curious - are you running some kind of debugger or profiling software through VSCode?
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.
> 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.
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.
> not familiar with how incredibly fast desktop applications used to be decades ago
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.
Some people can't tell the difference between 17 ms of latency and 68 (4 frames at 60hz), while some can't bear it.
unless one is playing e-sports with vscode, i dont think a latency of less than 100ms is something to worry about at all.
I know it's electron and a resource hog, meanwhile I virtually never need to reboot it and it never lags for me and I can't recall it crashing on me. Maybe I don't type fast enough to notice some of the laggy behavior but that's how I'm conditioned to believe it's just fine for me and I run it on a MB Air. I've used several IDE's over the years and feel like if I had something performance-wise to complain about I would have noticed it by now.
>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?
Decades ago also occurred decades after that. The average desktop app in 2003 felt faster than the average desktop app in 2023. The fact that you chose an app from 1983 shows you're intentionally dishonest.
I don't think he is intentionally dishonest. When I read "decades ago", I thought "three or more", roughly the same way "several" works.
It's all about tradeoffs. I like the features I get from VSCode and find its ergonomics outweigh other editors enough that I choose it over them, even if it may not be as fast. Am I conditioned or stupid?
(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.)
I think performance complaints about vscode are either from bad extensions/too many OR poor system resources.
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...
Your experience is not representative. Input latency of hundreds of milliseconds isn't something anybody I know would tolerate.
They probably have a powerful computer for $10k and don't understand that many people don't.
I've never ever run it on a $10K computer. It's quick enough on a Surface Go 2 (albeit in Linux, not on Windows). It's quick enough on an eight year old 2.7ghz i5 MacBook Pro. And it's even not shockingly awful on an 8GB Raspberry Pi 4B.
>> how incredibly fast desktop applications used to be decades ago
Are you still using that same computer from decades ago?
If the applications could be fast on that computer, why can't today's applications be fast on the same computer?
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.
Language servers are slow. Nobody could have predicted this since on paper json for process to process communication seems like a very sound choice, if the geniuses at microsoft could not solve such a difficult problem then surely this was the best option out of all the potential bad ones.
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.
Yes, Visual Studio is unbearably slow for me, even with tiny projects, whereas VSC seems snappy, even with larger projects.
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.
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.
Make it work, then make it fast is in most cases what you should do.
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.
Everyone should do a stint coding in vim, you learn so much about the things an IDE hides from you, and your terminal skills grow exponentially.
It's unfortunate that oni2 development stopped.
It had the promise of all the benefits of VS Code, but performance of a native app.
“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.”
There’s a word for what you are trying to explain. The word is “fix”.
VSCode is slow at… what? Is your computer from the 90s?
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.
Now imagine that you are doing a development on embedded platform - To the compilation time you will add time to load the application and time to boot it up.
> 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.
!!!
VSCode as fast as IntelliJ, Eclipse, PyCharm, Visual Studio.
(And anyone upset about Electron install sizes has clearly never used any of the above.)
To be fair, non-electron full-fat Visual Studio is also a pig.
Calling it a pig is an understatement. It is unbearably slow. I have no idea how they managed to make a native app so slow.
I am working as embedded software developer and VSCode is extremaly fast compared to its first competitor - Eclipse.
The irony is here by far so many devs don’t mind the speed?
A statement like this just makes me think most developers are the passengers in that episode of futurama where the brains take over and make everyone stupid.
"I'm sending in more trains!" [0]
Only the trains are additional layers of abstraction and the accompanying bloat.
VSCode is a good tool, but it’s unbearably slow
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.
If vscode slowed down for you it might mean you installed too many extensions.
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.
As I stated, I have four plug-ins.
If VSCode can't handle four plug-ins, it isn't fit for purpose.
Guys you should buy yourself a good MacBook because VSCode is damn good and fast on MacBooks
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.
Intellij does this in constant time because it has AST functionality built in.
Don't forget, NO multi-screen/window support, which is ridiculous. Apparently everybody code on 40" TV screen or something, rofl.
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.
That really depends. I used it on the same machine and it was fine enough on linux and completely unusable on windows. Same extensions, same project.
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
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.
I use vscode for interactive python development with Jupyter notebooks and live markdown rendering, and developing on WSL on windows. Does sublime support that? Vscode has the advantage that virtually every programming language and functionality you can think of, it has a plugin for it. Does sublime have similar support?
Everyone saying "This isn't a speedup, this is VSCode stopping being dumb" hasn't read carefully enough:
The speedup is from taking extension code built on a limited API and implementing it inside VSCode, using more information while doing so.
I read it as extension developers will never be able to match core since their api is limited.
I mean, yes? That's kind of the point of extensions; to provide additional functionality through specific APIs.
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.
Emacs stands in stark contrast to this claim, though. Some things do get moved into native code so that it can run faster, but at large most of it is implemented in the same code and paths that everyone has access to at runtime.
(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.
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.
Thanks! Macroexpanded:
Making bracket pair colorization faster - https://news.ycombinator.com/item?id=28692470 - Sept 2021 (265 comments)
Do people really like this type of syntax highlighting? The screenshots in the article to me are a hard to read color soup.
It's very useful when trying to find matching brackets in code!
In just basic Vim, there's highlighting such that if the cursor is over a start bracket (or end bracket), the opposite bracket is highlighted. I do find that very helpful indeed to find matching brackets (or where a bracket is missing), but I can't quite see why I'd need to have the colorization as well. Essentially I guess I can see colorization as 'highlighting' multiple brackets at once. Any way you could convince me that having this multiple identification has been preferable to the single identification?
> In just basic Vim, there's highlighting such that if the cursor is over a start bracket (or end bracket), the opposite bracket is highlighted.
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.
I recently switched from an old VScode version, which has only the click dependent matching, to the new version which has it with color highlighting. The difference is that you can match brackets pretty much immediately by glancing at them. It's convenient because it is quicker.
Gotchagotcha, so yeah, to some extent eliminates the time taken to highlight individual brackets at the cost of adding some visual complexity. Thanks.
I'm a big fan. My source code looks like a rave. I think it depends on your neurotype quite a bit though.
Yeah, I find the 'every symbol has a color' highlighting to be difficult to parse.
When everything is colorful, nothing stands out.
I agree. That’s a bit much.
Yep, it's great
Speed and performance improvements like this are why VSCode has passed Atom and other editors over time.
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. (-:
That is what tree-sitter is, I think? https://tree-sitter.github.io/tree-sitter/
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.
I'm sorry but I still prefer sublime text, and it finally fixed syntax folding!
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.
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 mean you don't need a cloud connected AI to significantly improve your experience in VS Code (vs basic token autocomplete).
Just installing the proper LSP for the language you work in makes a world of difference.
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?
I specialize in software perf & scalability, so read nearly everything I can on the subject, especially concrete cases like this!
That functionality looks pretty nice, anyone knows of an extension to do that in vim/nvim ?
Such an awesome article to read.. how something `simple` can be extremely challenging to execute
I get scolded for to many ifs haha.
I'll take verbose code over code golf any day.
Cool, maybe now they can add native titlebar functionality that real document apps have?
And the project referenced is no longer available (or needed, apparently?)
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.
this is old an did appear long time ago already on HD already...
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.
Monolith vs micro kernels, next round.
[2021]
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.
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 the "normal" version, see your eye doc...
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.
just the ability to change the bracket colors with reasonable default selections for colorblindness seems like a more than reasonable request
I’m not colorblind but I would wholeheartedly agree because I know colorblind guys
The extension already had a setting to tune the color palette even before it was merged into VSCode core.
Modus Operandi provides accessibility options for colored bracket pairs in Emacs out of the box.
I use a space indent colorizer plugin that I use a grey scale color scheme with.
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!)
Maybe they could use a superscript or subscript number instead?
Can't you just define the symbol color pallet in options? (I'm not a vscode user, I use JetBrains and I just define my own colors)
You absolutely can define your own colours. You can even have different colour pools per bracket type ([] () {}) if you want.
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?
Any interest in working together on a new extension?
What would be the possible solution ? Change size ? High contrast fg/Bg combinations ? Special UTF characters?
A different spectrum per type of colorblindness. It should work fine, unless you're completely blind to all colors, which is a very small proportion of colorblindness, most are only lacking perception of one out of three colors.
You can already do that: in the settings.json under workbench.colorCusomizations, change editorBracketHighlight.foregroundX where X is the level of bracketing you want to modify.
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.
Mathematic notation uses subtle tweaks/additive glyphs to the same characters all the time.
Subtle distinctions in font weight or italic-ness? Variable fonts give a lot of options.
See XKCD: "How standards proliferate".
No, that's not relevant and I think you know it, funny man
No mature, sensible code allows for 10x performance improvement (let alone...). Every time I see a statement like this I take it as a confession.
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.
You didn't even bother reading the article, did you? The performance increase was achieved by inlining a third-party extension into VSCode itself.
The code was both mature and sensible _within the limits of the environment and API available to it_.
The VSCode team took it out of that environment completely, which opened up a huge number of optimization possibilities.
But these "micro optimizations" aren't going to win anything!
Just keep everything slow and then everything will be alright.
This is not micro optimization. This is fixing a known performance issue.