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