11 ms·

If you can make something 10k x faster you didn’t so much fix it as just switch it to working correctly as it should have in the first place. VSCode is a good

by voz_ 3y ago

If you can make something 10k x faster you didn’t so much fix it as just switch it to working correctly as it should have in the first place. VSCode is a good tool, but it’s unbearably slow, and it breaks my heart that so much development has converged on something written in electron with such a low regard for performance by any measure.

rusl1 3y ago
Guys you should buy yourself a good MacBook because VSCode is damn good and fast on MacBooks
Solvency 3y ago
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.
- conductr 3y ago
  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.
- edgyquant 3y ago
  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.
  - Atotalnoob 3y ago
    Live share is an amazing thing that Microsoft demos. Doesn't really work (in my experience) in the real world...
  - dlisboa 3y ago
    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.
    - nickelpro 3y ago
      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.
- drcongo 3y ago
  [flagged]
  - ddoolin 3y ago
    There's a difference between "bringing up its slowness" and telling everyone else it's slow for them, too, and they're just crazy.
- ddoolin 3y ago
  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.
- drcongo 3y ago
  [flagged]
- deleted 3y ago
  [deleted]
- zwily 3y ago
  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.)
  - Atotalnoob 3y ago
    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...
- dimmke 3y ago
  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.
- phpisthebest 3y ago
  >> how incredibly fast desktop applications used to be decades ago Are you still using that same computer from decades ago?
  - xigoi 3y ago
    If the applications could be fast on that computer, why can't today's applications be fast on the same computer?
- chrisweekly 3y ago
  Your experience is not representative. Input latency of hundreds of milliseconds isn't something anybody I know would tolerate.
- bemusedthrow75 3y ago
  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?
  - bemusedthrow75 3y ago
    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”.
- flohofwoe 3y ago
  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.
- bigbillheck 3y ago
  > 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.
  - Solvency 3y ago
    Try again. https://twitter.com/jmmv/status/1671670996921896960 https://twitter.com/jmmv/status/1671670996921896960
- NovemberWhiskey 3y ago
  >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?
  - Solvency 3y ago
    https://twitter.com/jmmv/status/1671670996921896960 https://twitter.com/jmmv/status/1671670996921896960
  - yCombLinks 3y ago
    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.
    - mtizim 3y ago
      I don't think he is intentionally dishonest. When I read "decades ago", I thought "three or more", roughly the same way "several" works.
- AnIdiotOnTheNet 3y ago
  > 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 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.
- grog454 3y ago
  Some people can't tell the difference between 17 ms of latency and 68 (4 frames at 60hz), while some can't bear it.
  - chii 3y ago
    unless one is playing e-sports with vscode, i dont think a latency of less than 100ms is something to worry about at all.
- xigoi 3y ago
  They probably have a powerful computer for $10k and don't understand that many people don't.
  - bemusedthrow75 3y ago
    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.
ramraj07 3y ago
The irony is here by far so many devs don’t mind the speed?
- AnIdiotOnTheNet 3y ago
  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. [0] https://www.youtube.com/watch?v=-hyttagGsz0 https://www.youtube.com/watch?v=-hyttagGsz0
jaywalk 3y ago
It's not the fastest IDE out there, but it's certainly not unbearably slow.
- akkad33 3y ago
  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.
- 3836293648 3y ago
  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
KeplerBoy 3y ago
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.
- deepspace 3y ago
  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.
vbezhenar 3y ago
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.
- stewartmcgown 3y ago
  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.
  - lfkdev 3y ago
    Weird, i often opened files with hundreds of thousands of code lines without any problem. We do have very modern Workstations at work though.
  - chii 3y ago
    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 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 } 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.
    - wongarsu 3y ago
      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.
tibordp 3y ago
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.
- luckman212 3y ago
  What plugin are you using to open workspaces via SSH?
  - arijun 3y ago
    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.
  - tibordp 3y ago
    Just the standard Remote-SSH https://code.visualstudio.com/docs/remote/ssh https://code.visualstudio.com/docs/remote/ssh
  - singlow 3y ago
    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.
- 3y ago
ukFxqnLa2sBSBf6 3y ago
VSCode is slow at… what? Is your computer from the 90s?
zdragnar 3y ago
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.
- wudangmonk 3y ago
  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.
noselasd 3y ago
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.
- Zetice 3y ago
  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.
dumdumchan 3y ago
Intellij does this in constant time because it has AST functionality built in.
deleted 3y ago
[deleted]
david2ndaccount 3y ago
> 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 <https://twitter.com/rygorous/status/1271296834439282690?lang=en https://twitter.com/rygorous/status/1271296834439282690?lang...>
- seventhson 3y ago
  It 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).
alberth 3y ago
It's unfortunate that oni2 development stopped. It had the promise of all the benefits of VS Code, but performance of a native app. https://v2.onivim.io https://v2.onivim.io
HL33tibCe7 3y ago
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.
lkbm 3y ago
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.
jve 3y 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 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...
- brirec 3y ago
  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.
reaperducer 3y ago
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.
- IceSentry 3y ago
  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.
  - reaperducer 3y ago
    As I stated, I have four plug-ins. If VSCode can't handle four plug-ins, it isn't fit for purpose.
XCSme 3y ago
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.
akkad33 3y ago
What is faster than vscode? I've tried emacs and intellij and both have slow start up, break up and cause issues more often
- whalesalad 3y ago
  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.
  - akkad33 3y ago
    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?
bilalq 3y ago
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.
- paulddraper 3y ago
  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
  - geodel 3y ago
    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.
    - JohnFen 3y ago
      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.
      - frogstomp19 3y ago
        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.
flohofwoe 3y ago
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.
eikenberry 3y ago
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.
- TheLoafOfBread 3y ago
  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.
dsab 3y ago
I am working as embedded software developer and VSCode is extremaly fast compared to its first competitor - Eclipse.
paulddraper 3y ago
!!! VSCode as fast as IntelliJ, Eclipse, PyCharm, Visual Studio. (And anyone upset about Electron install sizes has clearly never used any of the above.)
AnIdiotOnTheNet 3y ago
To be fair, non-electron full-fat Visual Studio is also a pig.
- deepspace 3y ago
  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.
Barrin92 3y ago
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.
hinkley 3y ago
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.
RektBoy 3y ago
Don't forget, NO multi-screen/window support, which is ridiculous. Apparently everybody code on 40" TV screen or something, rofl.
deleted 3y ago
[deleted]
EMM_386 3y ago
> VSCode is a good tool, but it’s unbearably slow, and it breaks my heart that so much development has converged on something written in electron with such a low regard for performance by any measure. 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.
theRealMe 3y ago
“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”.

by voz_ 3y ago

rusl1 3y ago

Guys you should buy yourself a good MacBook because VSCode is damn good and fast on MacBooks

Solvency 3y ago

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.

conductr 3y ago
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.
edgyquant 3y ago
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.
- Atotalnoob 3y ago
  Live share is an amazing thing that Microsoft demos. Doesn't really work (in my experience) in the real world...
- dlisboa 3y ago
  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.
  - nickelpro 3y ago
    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.
drcongo 3y ago
[flagged]
- ddoolin 3y ago
  There's a difference between "bringing up its slowness" and telling everyone else it's slow for them, too, and they're just crazy.
ddoolin 3y ago
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.
drcongo 3y ago
[flagged]
deleted 3y ago
[deleted]
zwily 3y ago
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.)
- Atotalnoob 3y ago
  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...
dimmke 3y ago
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.
phpisthebest 3y ago
>> how incredibly fast desktop applications used to be decades ago Are you still using that same computer from decades ago?
- xigoi 3y ago
  If the applications could be fast on that computer, why can't today's applications be fast on the same computer?
chrisweekly 3y ago
Your experience is not representative. Input latency of hundreds of milliseconds isn't something anybody I know would tolerate.
bemusedthrow75 3y ago
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?
- bemusedthrow75 3y ago
  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”.
flohofwoe 3y ago
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.
bigbillheck 3y ago
> 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.
- Solvency 3y ago
  Try again. https://twitter.com/jmmv/status/1671670996921896960 https://twitter.com/jmmv/status/1671670996921896960
NovemberWhiskey 3y ago
>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?
- Solvency 3y ago
  https://twitter.com/jmmv/status/1671670996921896960 https://twitter.com/jmmv/status/1671670996921896960
- yCombLinks 3y ago
  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.
  - mtizim 3y ago
    I don't think he is intentionally dishonest. When I read "decades ago", I thought "three or more", roughly the same way "several" works.
AnIdiotOnTheNet 3y ago
> 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 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.
grog454 3y ago
Some people can't tell the difference between 17 ms of latency and 68 (4 frames at 60hz), while some can't bear it.
- chii 3y ago
  unless one is playing e-sports with vscode, i dont think a latency of less than 100ms is something to worry about at all.
xigoi 3y ago
They probably have a powerful computer for $10k and don't understand that many people don't.
- bemusedthrow75 3y ago
  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.

ramraj07 3y ago

The irony is here by far so many devs don’t mind the speed?

AnIdiotOnTheNet 3y ago
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. [0] https://www.youtube.com/watch?v=-hyttagGsz0 https://www.youtube.com/watch?v=-hyttagGsz0

jaywalk 3y ago

It's not the fastest IDE out there, but it's certainly not unbearably slow.

akkad33 3y ago
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.
3836293648 3y ago
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

KeplerBoy 3y ago

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.

deepspace 3y ago
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.

vbezhenar 3y ago

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.

stewartmcgown 3y ago
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.
- lfkdev 3y ago
  Weird, i often opened files with hundreds of thousands of code lines without any problem. We do have very modern Workstations at work though.
- chii 3y ago
  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 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 } 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.
  - wongarsu 3y ago
    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.

tibordp 3y ago

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.

luckman212 3y ago
What plugin are you using to open workspaces via SSH?
- arijun 3y ago
  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.
- tibordp 3y ago
  Just the standard Remote-SSH https://code.visualstudio.com/docs/remote/ssh https://code.visualstudio.com/docs/remote/ssh
- singlow 3y ago
  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.
3y ago

ukFxqnLa2sBSBf6 3y ago

VSCode is slow at… what? Is your computer from the 90s?

zdragnar 3y ago

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.

wudangmonk 3y ago
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.

noselasd 3y ago

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.

Zetice 3y ago
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.

dumdumchan 3y ago

Intellij does this in constant time because it has AST functionality built in.

deleted 3y ago

[deleted]

david2ndaccount 3y ago

> 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 <https://twitter.com/rygorous/status/1271296834439282690?lang=en https://twitter.com/rygorous/status/1271296834439282690?lang...>

seventhson 3y ago
It 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).

alberth 3y ago

It's unfortunate that oni2 development stopped. It had the promise of all the benefits of VS Code, but performance of a native app. https://v2.onivim.io https://v2.onivim.io

HL33tibCe7 3y ago

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.

lkbm 3y ago

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.

jve 3y 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 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...

brirec 3y ago
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.

reaperducer 3y ago

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.

IceSentry 3y ago
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.
- reaperducer 3y ago
  As I stated, I have four plug-ins. If VSCode can't handle four plug-ins, it isn't fit for purpose.

XCSme 3y ago

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.

akkad33 3y ago

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

whalesalad 3y ago
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.
- akkad33 3y ago
  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?

bilalq 3y ago

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.

paulddraper 3y ago
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
- geodel 3y ago
  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.
  - JohnFen 3y ago
    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.
    - frogstomp19 3y ago
      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.

flohofwoe 3y ago

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.

eikenberry 3y ago

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.

TheLoafOfBread 3y ago
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.

dsab 3y ago

I am working as embedded software developer and VSCode is extremaly fast compared to its first competitor - Eclipse.

paulddraper 3y ago

!!! VSCode as fast as IntelliJ, Eclipse, PyCharm, Visual Studio. (And anyone upset about Electron install sizes has clearly never used any of the above.)

AnIdiotOnTheNet 3y ago

To be fair, non-electron full-fat Visual Studio is also a pig.

deepspace 3y ago
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.

Barrin92 3y ago

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.

hinkley 3y ago

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.

RektBoy 3y ago

Don't forget, NO multi-screen/window support, which is ridiculous. Apparently everybody code on 40" TV screen or something, rofl.

deleted 3y ago

[deleted]

EMM_386 3y ago

> VSCode is a good tool, but it’s unbearably slow, and it breaks my heart that so much development has converged on something written in electron with such a low regard for performance by any measure. 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.

theRealMe 3y ago

“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”.