4 ms·

Are there benchmarks VS Code vs Atom? I'm using Sublime Text 3 but these two text editors have many more extensions/packages than ST3 and while I don't want to

Are there benchmarks VS Code vs Atom? I'm using Sublime Text 3 but these two text editors have many more extensions/packages than ST3 and while I don't want to move to a slower text editor, the packages seem to good too pass up.

Waterluvian 8y ago
The thing that sucks, in my experience, is that the "fastness" of a text editor doesn't translate into productivity the way the abundance of plugins and support and popularity will. But the slower ones just manifestly feel so irritating once you're used to the speed.
basil-rash 8y ago
On specifically startup time for large files (narrow use case, but thats what we got), there's this comment from user jakear from a while back on an Atom 1.28 thread [1]: 1.1GB file, 10M lines. Code: ~10s, smooth scrolling, instant jumping. Sublime: ~50s, smooth scrolling, instant jumping. Atom: ~10s, smooth scrolling, very choppy jumping: ~5s loads per jump (also got some error messages about text too large for buffer) 1.0GB file, 40k lines. Code: ~15s, scrolling somewhat choppy, quick jumping Sublime: Application not responding after ~60s, waitied another 60s, no change. Same behavior each of the two times I attempted. Atom: ~8s, smooth scroll, ~30s per jump, occasional "Editor is taking too long to load" messages. Note: Atom enforces a maximum line length of ~500 chars before it wraps regardless of word wrap setting. This means the 8s load was only showing a couple lines worth of content. I find this restriction not acceptible for the long-line test case, but including anyways for completeness) Full "report": https://pastebin.com/wUv8PSgp https://pastebin.com/wUv8PSgp [1]: https://news.ycombinator.com/item?id=17369898 https://news.ycombinator.com/item?id=17369898
tracker1 8y ago
At home, I'm on an i7-4790K, my work laptop is an i7-8650U, so ymmv. I've never found Code to be particularly slow, and will generally load in a couple seconds. I tend to have it open most of the day on the project(s) I'm actively working on. The benefits of the integrated terminal alone probably saves me more time than I ever spend waiting for it to load. It's always been very responsive in the application, and worst case scenario I've had is on occassion the syntax highlighting or context auto-complete may have a delay. But that doesn't stop me from being able to continue typing by hand and is generally as good or better than Sublime. The extensions are all around REALLY nice to have. Being able to add support for more languages via extension has been great, what little I've used of that. And the integrated debugger has been very usable when I've used it. Git integration and Diffing could use a bit more work, but that's true of even dedicated Git applications. I've really been beyond appreciative of the iterative improvements as well. Every release I notice something that I like in the release notes. I will say I did like the old open-docs layout more than the Tabs once I had gotten used to it. It still works okay, but I didn't appreciate that one regression in behavior. But most were more used to tabs, and I understand the resistance.

Waterluvian 8y ago

The thing that sucks, in my experience, is that the "fastness" of a text editor doesn't translate into productivity the way the abundance of plugins and support and popularity will. But the slower ones just manifestly feel so irritating once you're used to the speed.

basil-rash 8y ago

On specifically startup time for large files (narrow use case, but thats what we got), there's this comment from user jakear from a while back on an Atom 1.28 thread [1]: 1.1GB file, 10M lines. Code: ~10s, smooth scrolling, instant jumping. Sublime: ~50s, smooth scrolling, instant jumping. Atom: ~10s, smooth scrolling, very choppy jumping: ~5s loads per jump (also got some error messages about text too large for buffer) 1.0GB file, 40k lines. Code: ~15s, scrolling somewhat choppy, quick jumping Sublime: Application not responding after ~60s, waitied another 60s, no change. Same behavior each of the two times I attempted. Atom: ~8s, smooth scroll, ~30s per jump, occasional "Editor is taking too long to load" messages. Note: Atom enforces a maximum line length of ~500 chars before it wraps regardless of word wrap setting. This means the 8s load was only showing a couple lines worth of content. I find this restriction not acceptible for the long-line test case, but including anyways for completeness) Full "report": https://pastebin.com/wUv8PSgp https://pastebin.com/wUv8PSgp [1]: https://news.ycombinator.com/item?id=17369898 https://news.ycombinator.com/item?id=17369898

tracker1 8y ago

At home, I'm on an i7-4790K, my work laptop is an i7-8650U, so ymmv. I've never found Code to be particularly slow, and will generally load in a couple seconds. I tend to have it open most of the day on the project(s) I'm actively working on. The benefits of the integrated terminal alone probably saves me more time than I ever spend waiting for it to load. It's always been very responsive in the application, and worst case scenario I've had is on occassion the syntax highlighting or context auto-complete may have a delay. But that doesn't stop me from being able to continue typing by hand and is generally as good or better than Sublime. The extensions are all around REALLY nice to have. Being able to add support for more languages via extension has been great, what little I've used of that. And the integrated debugger has been very usable when I've used it. Git integration and Diffing could use a bit more work, but that's true of even dedicated Git applications. I've really been beyond appreciative of the iterative improvements as well. Every release I notice something that I like in the release notes. I will say I did like the old open-docs layout more than the Tabs once I had gotten used to it. It still works okay, but I didn't appreciate that one regression in behavior. But most were more used to tabs, and I understand the resistance.