4 ms·
As was pointed out numerous times in that thread, they aren't 'embarassing benchmark numbers', they are 'irrelvant benchmark numbers', because no such 'slowdown
by allover 10y ago
As was pointed out numerous times in that thread, they aren't 'embarassing benchmark numbers', they are 'irrelvant benchmark numbers', because no such 'slowdown' is actually felt by most developers that try VS Code.
> But they have no place in text editing.
Their popularity proves otherwise.
- aphextron 10y ago>they are 'irrelvant benchmark numbers', because no such 'slowdown' is actually felt by most developers that try VS Code I don't think that's true at all. I have tried both VSCode and Atom, and immediately dropped them both after they crashed opening a file of a few thousand lines.
- fenomas 10y agoYMMV. I've been a daily user of Code for about a year and I've never seen it crash. Never seen it pause for a perceptible amount of time, that I can recall. Granted, I haven't tried editing any 10MB XML files with it, but then I've only been using it, not benchmarking it. Sure it uses more memory than nano, but why would I care about that?
- konart 10y agoThis. Text editor can't handle openning log file. (no need to highlight anything, complete anything, scan the structure etc. Just show me the damn log!) With the latest updates they are now able to open files up to 10Mb, wow.
- Forlien 10y agoIs this a case of a more specialized tool (with fewer but more focused features)? For example, you can view email in vim, and I'm sure you'd get better performance than Gmail for large emails but very few developers I know use vim for that.
- thiht 10y agoThat's not the use case of people using full featured editors. For the same reason I don't open log files with Intellij or Visual Studio, I don't open them with VS Code. I use VS Code as a code editor, not as a text editor. If I want to open a log file, I use Sublime or Vim.