3 ms·

I think what the poster you replied to may have been referring to is that the marginal cost once the editor is open is roughly zero. If VS Code is being used, a

I think what the poster you replied to may have been referring to is that the marginal cost once the editor is open is roughly zero. If VS Code is being used, a user can hit Ctrl/Cmd-N and have a new empty text field in no time. Similarly, opening a text file is so quick that I can't perceive any passing of time between clicking on it in the file tree and seeing the file open. Perhaps users with slower computers have a different experience?

robenkleene 5y ago
The second example I posted, illustrating that VSCode is 14 times slower than BBEdit, was opening a file with VSCode already open (it's not obvious, but VSCode was already open in both recordings, so this difference has nothing to do with its launch time). There's some truth to your comment though, in that VSCode's optimizations are very on rails, i.e., if you go the slightest bit off the beaten path (like I opened a file from the Finder, instead of from the sidebar, in the BBEdit/VSCode video), then VSCode approach to optimization falls apart (you can find accounts of the tricks VSCode uses to appear fast online, there's a lot of smoke and mirrors based around specific workflows -- I think making a new tab is actually the example they use). It wouldn't surprise me if part of the reason I perceive it as so slow is I expect every feature to be fast, not just to most common ones. And I think this is a perfectly fair metric to measure by. Emacs, Vim, BBEdit, and Sublime Text are all fast at everything they do, therefore I think it's fair to call VSCode a slow editor, even if technically it's average for a couple of features.
alpaca128 5y ago
Often VS Code literally takes longer to process a single key input than Vim takes to start, load all plugins and open a session with multiple files on my machine. Granted, it's not a high-end workstation, just a laptop from 2016. But I don't think it's slow; when Vim first released it could have beaten the fastest supercomputer. Now of course that's a matter of perspective, but I hope I'm not the only one who thinks editing a package.json shouldn't make any modern PC sweat.

robenkleene 5y ago

The second example I posted, illustrating that VSCode is 14 times slower than BBEdit, was opening a file with VSCode already open (it's not obvious, but VSCode was already open in both recordings, so this difference has nothing to do with its launch time). There's some truth to your comment though, in that VSCode's optimizations are very on rails, i.e., if you go the slightest bit off the beaten path (like I opened a file from the Finder, instead of from the sidebar, in the BBEdit/VSCode video), then VSCode approach to optimization falls apart (you can find accounts of the tricks VSCode uses to appear fast online, there's a lot of smoke and mirrors based around specific workflows -- I think making a new tab is actually the example they use). It wouldn't surprise me if part of the reason I perceive it as so slow is I expect every feature to be fast, not just to most common ones. And I think this is a perfectly fair metric to measure by. Emacs, Vim, BBEdit, and Sublime Text are all fast at everything they do, therefore I think it's fair to call VSCode a slow editor, even if technically it's average for a couple of features.

alpaca128 5y ago

Often VS Code literally takes longer to process a single key input than Vim takes to start, load all plugins and open a session with multiple files on my machine. Granted, it's not a high-end workstation, just a laptop from 2016. But I don't think it's slow; when Vim first released it could have beaten the fastest supercomputer. Now of course that's a matter of perspective, but I hope I'm not the only one who thinks editing a package.json shouldn't make any modern PC sweat.