These tests perfectly reflect my experience of using Sublime Text. It's a workhorse that does what I want without complaint within a time frame that might not be instant but is never Too Long™. I use other editors for other tasks, but I've bought ST twice and would be happy to keep buying it.
I honestly used Atom and Code prior to deciding to try Sublime. My experience has been the same as these results. Sublime is much quicker than either one. I do still like Vim (Neovim to be specific), but right or wrong that isn't what I am comparing to Sublime. I usually just compare Sublime, Code and Atom. Of which Sublime wins by a landslide (which you can more than likely blame on Electron).
I bought Sublime Text recently. I love it, but I was very disappointed to watch it become temporarily, but completely, unresponsive when opening a very large file on a network share.
I love comparisons like this. There's such a rush to get the new shiny thing, that sometimes we don't notice what we're giving up. I've been going back and forth between Atom, VS Code, and vim, for my programming for the past year, or so. I end up defaulting back to vim, for a variety of reasons. Speed is one of them (the bigger one is that nearly all of my testing happens on remote servers or headless VMs, so if I want to use an edit-test-commit cycle, which I nearly always do, vim is what I have).
There's a lot to like about the new editors, but it's a pretty big tradeoff, IMHO. Even on reasonable-sized files, I notice the speed difference, and sometimes Atom or VS Code do something pathological and end up making me wait an inordinate amount of time for it to sort itself out.
Also, Atom has improved quite a bit. It used to be remarkably slower than VS Code, and now it seems to be only marginally slower (though both are among the slowest in this bunch of tests, so it's faint praise to say Atom is "almost as fast as VS Code"). Nonetheless, Moore's law has given us a world in which even very, very, slow editors are Fast Enough(tm) for most of the work, most of the time.
Have you ever heard of sshfs? I've needed to do some work on headless computers lately and it has been a lifesaver. Basically it lets you mount a remote computer's filesystem over ssh, meaning you can edit everything in your main editor.
I'm in a similar spot but between VS Code and vi. Have you tried the vim extension for VS Code? In theory it would be an almost perfect solution but I can't seem to get it to feel natural. I might just need to dedicate more time to adjusting muscle memory.
The argument people have for Atom / VSCode is that you won't notice the tiny performance improvements with small files and you don't need massive files.
Perhaps I'm just a 'sensitive' soul, but I really do notice these minor differences in performance. If there is ever a slight slow down in the editor then it takes my focus off my work and onto the editor.
I 'feel it', rather than being able to put it down into specific testable specifics.
I use ST3 mostly and I instantly notice if switching tabs is taking fractionally longer or if undos/redos or scrolling is taking longer.
The only reason I don't switch to Vim is that ST3 is much more user friendly. So it means that I have to think too much about the commands in Vim which slows down my thinking - which is the equivalent slow down of having unresponsive editors.
> So it means that I have to think too much about the commands in Vim which slows down my thinking
If you use anything long enough, you no longer think about it. Indeed, the only time I think about how I do things in Vim is when someone asks "How did you do that?" I only thought it, and it happened. Recreating it can sometimes be a short puzzle.
I'm certain this is true for other people and their editors, or anything that you use so intrinsically that it's like breathing.
I also think that ST3 is faster/more-responsive than vim with plugins.
For example, in order to make vim an alternativet to ST, I have to use several plugins, such as snippets, youcompleteme, etc.. Once I do that, vim has a slight delay that I just can't stand.
It's impressive how Sublime perform well despite having so many advanced features. Too bad Atom.io doesn't manage to get its performance issues in order.
Since it's based on node-webkit, that will be difficult. I find it hard to understand why they thought building text editors in a web engine was a good idea. Cross-platform support seems to trump all other considerations.
I was actually pleasantly surprised by Atom's performance. It used to be remarkably slower than VS Code...like dramatically so. Now, it seems to be breathing down VS Code's neck, in terms of performance. (Both are the chubby kids huffing and puffing along at the back of the pack while being lapped by the other contenders, of course, but they're trying.)
I am a huge emacs fan, but there is a reason I still use vi/vim, and gasp, even nano regularly. It's on just about everything and is quick and simple.
Also, at first I wondered why vi wasn't on there, but for those of you who thought the same, nvi is berkely vi (TIL).
I like that emacs performs in the middle of the road in most of these cases, because it shows stability but room for improvement. Dissapointed with the large file results, but they are useful. (using vi on big files from now, it's a problem I run into more and more)
Emacs is much worse with long lines than it is with large files, and the test here uses 1,000 char lines. I'm not even sure I'd dare open a file that consisted of merely a single one of those.
However I've had no difficulty using it to view 3GByte files with 80-column lines. I don't have one handy to try but I did quickly load a 450MByte text file (6m lines, most 76 chars) and it took about 3 seconds to load.
For what it's worth, the real scourge with emacs seems to be people's bloaty config files. I have a fairly small .emacs with maybe five packages to load, takes about 1.2 seconds to open (and finish displaying) on my mac, about .2 seconds on my linux workstation. The editor itself actually starts up much quicker, about 110ms on my mac, 40ms on my workstation. Also, generally I use emacs daemon, so I don't really need to start it up at any point.
I don't tend to open files in excess of 100MiB, or do more than about 20k replaces in a file interactively, so I never really notice latency on operations.
Just jumping on the Emacs bandwagon here to Ask HN: does anyone have tips and tricks for profiling my real-world Emacs setup? Between perhaps a too-large .git repository, and all my loaded extensions, and perhaps spellchecking or font-lock, i'm sometimes not sure what's causing latency, and while i couldn't go back to Vim feature-wise, i do miss its speed.
This benchmarking may seem silly on a surface level, but when you are working in a large codebase like the Linux kernel or the Android open source project, the low speed of editors like atom is crippling to productivity.
Which is very unfortunate as atom is a rather nice editor from most other points of views.
That being said I've yet to find a good IDE even that holds up to being used in a workspace with the kernel and AOSP.
Hell, when I open up common javascript libraries (which should be the most closest thing to native considering that Atom is an electron app) I often have issues.
about year ago I was working in the illumos kernel codebase and was using sublime. It seemed to work well enough for what I was using it for, still was a bit hard to find the appropriate file quick enough though.
This comparison totally misses the the normal workflow for Emacs.
Nobody normally starts an Emacs instance to edit a file and quits it afterwards. Typically you run Emacs in server mode, and use emacsclient to instantly open whatever files you need.
By the same token, somebody could give low marks to IntelliJ or Eclipse because it may take a good 20-30 seconds for them to load.
I wonder how Acme[0][1], developed by Rob Pike for Plan 9 would compare. It feels fast and light, but I only ever use it for files lighter than a megabyte.
I've been using Atom for the past several months. I was using Sublime Text 3 before.
This confirms my observations that Atom is both significantly slower and also consumes more resources. I mean, the numbers speak for themselves: It uses at least an order of magnitude more RAM compared to most of the others, and common tasks are up to two orders of magnitude slower.
At first I thought the issue was my old laptop. But now I see the benchmarks, I'm definitely switching back to ST3.
Is this really a surprise though? It uses Electron, which loads an entire web browser just to do text editing and adds several layers of indirection which aren't needed by other editors like sublime.
My two cents; there's a ton of space for productivity improvement in editors. Projects that allow more and newer features is what I'm interested in.
I don't like the fact that Atom and VSCode are slow and memory hogs. I do like that fact they are running in a cross platform environment with access to canvas, webgl, svg, images, video, networking and more. I want to see where that integration leads. Whether it's inline diagrams or code flow diagrams in a separate pane or ???
I also like the idea that editors could be written to be more friendly to plugins and customization than previous editors. I get that emacs and vim can be customized but there is arguably room for improvement. Whether it's easier APIs, an in editor plugin browser/installer, or things like Microsoft's external code meta data protocol that potentially let's more editors share support for more languages.
Of course I want speed and I have not switched to either Atom or VScode yet but both seem like a step forward where as emacs, vim, and even sublime feel stuck in a previous generation of design
No Geany ? I love this editor. It's supports most languages(syntax) has some default compile-hotkeys for most languages.. Doesn't feel as clunky-slow as full-IDE's
CTRL + F'd to see if anyone else had mentioned Geany. The fact that it is cross platform as well as having great performance made it my go to. I use it on my underpowered Lubuntu laptop and my beefy Win i7 workstation.
I'd like to see Kate added. It's one of the most capable editors on desktop Linux and bundled by default on many distros. Curious how it performs in direct comparison!
One thing missing from the test is what options are being used in vim. I would like to see "vim -u NONE" added, which basically acts like pure vi. Yes, vim cannot really handle a 3GB xml file with syntax highlighting, but if you use "vim -u NONE" it is not a problem.
Solidifies how I felt about Atom. I'm unsure how people use it regularly. I found everything extremely slow. It's a pretty editor, but the speed of it is a killer.
I would be interested in seeing vim, nvim, and emacs performance using a slew of plugins to get to the point where their functionality is close to the features that sublime/atom/vscode have out of the box.
Emacs has many of those out of the box, you just need to tweak/enable them. The worst thing about Emacs is it's default settings, because the whole point of it's existence is customization to very niche and personal needs.
Same. I'm not really sure what it is, but the moment you add a few plugins to vim, you definitely notice a slowdown. I'm sure it's the abomination that vimL is.
I wouldn't, because none of that functionality is/should be involved in the simple tasks that were benchmarked in the article. If it still slows down these things by orders of magnitude, it has to be implemented sloppily, don't you think?
UltraEdit is an old but VERY fast editor with a crazy mount of features like diff and a hex editor. I sadly had to stop using it because their licensing is too restrictive (can't use windows license on linux; can't move windows license to another computer; online activation which only works x times and then you have to write to support ...).
I notice they don't include IntelliJ. I know it's not normally considered an editor, but it's worth noting just how much faster it is than other editors in this latency test.
https://pavelfatin.com/typing-with-pleasure/
Only faster with `editor.zero.latency.typing=true`, which I don't think is default. Othersise, IDEA has some of the highest latency in the tables I saw on that page. On windows worse that Eclipse, on Linux worse than Atom even.
IntelliJ is my daily driver, but god it's slow for me. I can't figure it out. It's OK, on my laptop, but when I plugin an external display it's performance tanks.
[+] [-] aeturnum|9 years ago|reply
[+] [-] jjuel|9 years ago|reply
[+] [-] cheald|9 years ago|reply
[+] [-] justin66|9 years ago|reply
[+] [-] SwellJoe|9 years ago|reply
There's a lot to like about the new editors, but it's a pretty big tradeoff, IMHO. Even on reasonable-sized files, I notice the speed difference, and sometimes Atom or VS Code do something pathological and end up making me wait an inordinate amount of time for it to sort itself out.
Also, Atom has improved quite a bit. It used to be remarkably slower than VS Code, and now it seems to be only marginally slower (though both are among the slowest in this bunch of tests, so it's faint praise to say Atom is "almost as fast as VS Code"). Nonetheless, Moore's law has given us a world in which even very, very, slow editors are Fast Enough(tm) for most of the work, most of the time.
[+] [-] ball_of_lint|9 years ago|reply
[+] [-] nikcub|9 years ago|reply
[+] [-] yAnonymous|9 years ago|reply
The development with web technologies means a big step forward in accessibility and usability and that's much more important to me.
For the rare case I do need to work on an XML with 100k lines, vim is still around and using a modern editor won't make it disappear.
[+] [-] icc97|9 years ago|reply
Perhaps I'm just a 'sensitive' soul, but I really do notice these minor differences in performance. If there is ever a slight slow down in the editor then it takes my focus off my work and onto the editor.
I 'feel it', rather than being able to put it down into specific testable specifics.
I use ST3 mostly and I instantly notice if switching tabs is taking fractionally longer or if undos/redos or scrolling is taking longer.
The only reason I don't switch to Vim is that ST3 is much more user friendly. So it means that I have to think too much about the commands in Vim which slows down my thinking - which is the equivalent slow down of having unresponsive editors.
[+] [-] a3n|9 years ago|reply
If you use anything long enough, you no longer think about it. Indeed, the only time I think about how I do things in Vim is when someone asks "How did you do that?" I only thought it, and it happened. Recreating it can sometimes be a short puzzle.
I'm certain this is true for other people and their editors, or anything that you use so intrinsically that it's like breathing.
[+] [-] terraforming|9 years ago|reply
For example, in order to make vim an alternativet to ST, I have to use several plugins, such as snippets, youcompleteme, etc.. Once I do that, vim has a slight delay that I just can't stand.
[+] [-] hartator|9 years ago|reply
[+] [-] elsurudo|9 years ago|reply
[+] [-] SwellJoe|9 years ago|reply
[+] [-] lawnchair_larry|9 years ago|reply
I hope this trend dies soon. The inmates are running the asylum.
[+] [-] zeveb|9 years ago|reply
Does it have any features which emacs — which outperforms it — lacks?
[+] [-] therealdrag0|9 years ago|reply
[+] [-] arca_vorago|9 years ago|reply
Also, at first I wondered why vi wasn't on there, but for those of you who thought the same, nvi is berkely vi (TIL).
I like that emacs performs in the middle of the road in most of these cases, because it shows stability but room for improvement. Dissapointed with the large file results, but they are useful. (using vi on big files from now, it's a problem I run into more and more)
[+] [-] to3m|9 years ago|reply
However I've had no difficulty using it to view 3GByte files with 80-column lines. I don't have one handy to try but I did quickly load a 450MByte text file (6m lines, most 76 chars) and it took about 3 seconds to load.
[+] [-] microcolonel|9 years ago|reply
I don't tend to open files in excess of 100MiB, or do more than about 20k replaces in a file interactively, so I never really notice latency on operations.
[+] [-] problems|9 years ago|reply
There's also addon tools like vlfi if you're editing very large files on a regular basis.
I'd be more interested in ~200MB instead of 3 GB as I find myself more frequently opening log files and XML exports in the 100-500MB range.
[+] [-] toothbrush|9 years ago|reply
[+] [-] robert_foss|9 years ago|reply
Which is very unfortunate as atom is a rather nice editor from most other points of views.
That being said I've yet to find a good IDE even that holds up to being used in a workspace with the kernel and AOSP.
[+] [-] andrewclunn|9 years ago|reply
[+] [-] dan353hehe|9 years ago|reply
[+] [-] nine_k|9 years ago|reply
Nobody normally starts an Emacs instance to edit a file and quits it afterwards. Typically you run Emacs in server mode, and use emacsclient to instantly open whatever files you need.
By the same token, somebody could give low marks to IntelliJ or Eclipse because it may take a good 20-30 seconds for them to load.
[+] [-] aphextron|9 years ago|reply
Is that seriously worth a >10x slow down to you?
[+] [-] black_knight|9 years ago|reply
[0]: http://acme.cat-v.org/ [1]: https://github.com/9fans/plan9port
[+] [-] dmit|9 years ago|reply
[+] [-] jhallenworld|9 years ago|reply
[+] [-] enraged_camel|9 years ago|reply
This confirms my observations that Atom is both significantly slower and also consumes more resources. I mean, the numbers speak for themselves: It uses at least an order of magnitude more RAM compared to most of the others, and common tasks are up to two orders of magnitude slower.
At first I thought the issue was my old laptop. But now I see the benchmarks, I'm definitely switching back to ST3.
[+] [-] problems|9 years ago|reply
[+] [-] greggman|9 years ago|reply
I don't like the fact that Atom and VSCode are slow and memory hogs. I do like that fact they are running in a cross platform environment with access to canvas, webgl, svg, images, video, networking and more. I want to see where that integration leads. Whether it's inline diagrams or code flow diagrams in a separate pane or ???
I also like the idea that editors could be written to be more friendly to plugins and customization than previous editors. I get that emacs and vim can be customized but there is arguably room for improvement. Whether it's easier APIs, an in editor plugin browser/installer, or things like Microsoft's external code meta data protocol that potentially let's more editors share support for more languages.
Of course I want speed and I have not switched to either Atom or VScode yet but both seem like a step forward where as emacs, vim, and even sublime feel stuck in a previous generation of design
[+] [-] rawoke083600|9 years ago|reply
[+] [-] Fuzzwah|9 years ago|reply
[+] [-] microcolonel|9 years ago|reply
[+] [-] sho_hn|9 years ago|reply
[+] [-] dhfhduk|9 years ago|reply
It seems to be available for Windows and OSX, but I haven't tried it on those platforms. Does anyone have any experience with that?
I suspect it's perceived as KDE-specific, which might be part of the reason it doesn't get more attention.
[+] [-] black_knight|9 years ago|reply
[+] [-] r0bfelty|9 years ago|reply
[+] [-] shalabhc|9 years ago|reply
I did some of these tests with Howl, here are the better numbers:
- Memory (hello.c): 22748 (RSS)
- Rehighlight test: about 3s
- Time used to load test.xml, jump to end of file and exit: 2.1s
[+] [-] eugenekolo2|9 years ago|reply
[+] [-] drewbailey|9 years ago|reply
[+] [-] Philipp__|9 years ago|reply
[+] [-] farresito|9 years ago|reply
[+] [-] lazyjones|9 years ago|reply
[+] [-] sdfghs5|9 years ago|reply
[+] [-] diroussel|9 years ago|reply
[+] [-] therealdrag0|9 years ago|reply
IntelliJ is my daily driver, but god it's slow for me. I can't figure it out. It's OK, on my laptop, but when I plugin an external display it's performance tanks.