6 ms·

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

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.
- Shrezzing 3y ago
  >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.
  - bemusedthrow75 3y ago
    They are indeed -- and it will avoid similarly costly stuff on anything you .gitignore.
- vbezhenar 3y ago
  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.
- asdajksah2123 3y ago
  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.
sebzim4500 3y ago
For the most part I agree with you but "miles away of any JS apps" is a low bar to cross.
- akkad33 3y ago
  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
  - pcl 3y ago
    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.
    - nickelpro 3y ago
      > 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
  - uoaei 3y ago
    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.
    - akkad33 3y ago
      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
  - marginalia_nu 3y ago
    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.
fragmede 3y ago
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.
- wenc 3y ago
  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.
  - ColonelPhantom 3y ago
    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.
  - CalChris 3y ago
    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.
- chinaman425 3y ago
  [dead]
- bick_nyers 3y ago
  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.
bamfly 3y ago
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.
- wiseowise 3y ago
  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 http://news.ycombinator.com/item?id=2822114.
- VHRanger 3y ago
  Sublime text is an editor, VS Code is an IDE, though? The featuresets aren't the same.
  - bamfly 3y ago
    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.
    - tredre3 3y ago
      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.
      - bamfly 3y ago
        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.

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.
Shrezzing 3y ago
>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.
- bemusedthrow75 3y ago
  They are indeed -- and it will avoid similarly costly stuff on anything you .gitignore.
vbezhenar 3y ago
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.
asdajksah2123 3y ago
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.

sebzim4500 3y ago

For the most part I agree with you but "miles away of any JS apps" is a low bar to cross.

akkad33 3y ago
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
- pcl 3y ago
  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.
  - nickelpro 3y ago
    > 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
- uoaei 3y ago
  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.
  - akkad33 3y ago
    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
- marginalia_nu 3y ago
  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.

fragmede 3y ago

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.

wenc 3y ago
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.
- ColonelPhantom 3y ago
  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.
- CalChris 3y ago
  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.
chinaman425 3y ago
[dead]
bick_nyers 3y ago
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.

bamfly 3y ago

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.

wiseowise 3y ago
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 http://news.ycombinator.com/item?id=2822114.
VHRanger 3y ago
Sublime text is an editor, VS Code is an IDE, though? The featuresets aren't the same.
- bamfly 3y ago
  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.
  - tredre3 3y ago
    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.
    - bamfly 3y ago
      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.