| Yeah, all I need to do to reliably show the drastic performance difference is open 5 different windows with 5 different versions of our monorepo. I frequently need to do that when e.g. reviewing different branches and, say, running some of the test suites or whatever — work where I want to leave the computer doing something in that branch, while I myself switch to reviewing or implementing some other feature. When I start VS Code, it often re-opens all the windows, and it is slow as hell right away (on Linux 14900K + fast SSD + 64GB RAM, or on macOS on a Mac Studio M2 Ultra with 64GB RAM). I'll save a file and it will be like jank...jank... File Save participants running with a progress bar. (Which, tbh, is better than just being that slow without showing any indication of what it is doing, but still.) I've tried to work with it using one window at a time, but in practice I found it is better for my needs to just quit and relaunch it a few times per day. I try Zed (and Sublime, and lapce, and any other purportedly performant IDE or beefed-up editor that I read about on this website or similar) like every couple months. But VS Code has a very, very large lead in features, especially if you are working with TypeScript. The remote development features are extremely good; you can be working from one workstation doing all the actual work on remote Linux containers — builds and local servers, git, filesystem, shell. That also means you can sit down at some other machine and pick up right where you left off. The TypeScript completion and project-wide checking is indeed way slower than we want it to be, but it's also a lot better than any other editor I've seen (in terms of picking up the right completions, jumping to definition, suggesting automatic imports, and flagging errors). It works in monorepos containing many different projects, without explicit config. And then there's the extensions. I don't use many (because I suspect they make it even slower). But the few I do use I wouldn't want to be without (e.g. Deno, Astro, dprint). Whatever your sweet set is, the odds are they'll have a VS Code extension, but maybe not the less popular editors. So there is this huge gravity pulling me back to VS Code. It is slow. It is, in fact, hella fucking slow. Like 100x slower than you want, at many basic day-to-day things. But for me so far just buying the absolute fastest machine I can is still the pragmatic thing to do. I want Zed to succeed, I want lapce to succeed, I want to use a faster editor and still do all these same things — but not only have I failed so far to find a replacement that does all the stuff I need to have done, it also seems to me that VS Code's pace of development is pretty amazing, and it is advancing at a faster clip than any of these others. So while it may be gated in some fundamental way on the performance problem, because of its app architecture, on balance the gap between VS Code and its competitors seems to be widening, not shrinking. |
I wonder if you have some problem on your machine/setup? I'd investigate it - try some benchmarking. It's open source so you don't me afraid looking under the hood to see what's happening.
> I'll save a file and it will be like jank...jank... File Save participants running with a progress bar.
I don't see that at all. Saving is instant/transparent to me.
There is so much possible configuration that could cause an issue e.g. if you have "check on save" from an an extension then you enter "js jank land" where plugins take plugins that take plugins all configured in files with dozens of options, weird rules that change format every 6 months e.g. your linter might take plug-ins from your formatter, your test framework, your ui test framework, hot reload framework, your bundler, your transpile targets...
If saving is really slow then I would suspect something like an extension is wandering around node_modules. Probing file access when you see jank might reveal that.