61 ms·

Text Editor Performance Comparison

330 points by gnuvince 10y ago

robert_foss 10y ago
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.
- andrewclunn 10y ago
  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.
  - shalabhc 10y ago
    Can you give a ballpark estimate of the sizes of these files?
- dan353hehe 10y ago
  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.
hartator 10y ago
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.
- SwellJoe 10y ago
  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.)
  - bastawhiz 10y ago
    That's interesting to hear, because I've tried Atom three times now and the biggest deal-breaker every single time has been performance. Around the first release, there was noticeable lag as I typed. About a year later, tabbing through find results was just absurdly slow. More recently, opening a multi-megabyte JSON file with syntax highlighting was an inexcusably painful experience. I really, really want to use and support Atom, but the performance compared to Sublime has just been atrocious (in my experience).
    - SwellJoe 10y ago
      Oh, it's still slow. Pathologically so in some cases. But, so is VS Code. But, Atom's speed has become manageable in recent versions. I rarely find myself unable to work with a big file in Atom. For code, I rarely see files bigger than a few thousand lines (and never produce files that large myself), and Atom handles them OK (not great, but acceptable, given the other benefits of the tool). VS Code is still better, and of course, vim smokes them both. But, there are trade offs, and Atom has a lot of cool features. I wouldn't use it for really large files, however. It really shows its ass in those cases (as the XML file test here shows).
  - hartator 10y ago
    My main issue with Atom.io performance is typing lag, it's kind of my main thing for an editor unfortunately. I love Atom.io otherwise.
    - SwellJoe 10y ago
      I don't notice typing lag, anymore. Just now I opened it up and tried to get ahead of it by slamming flat hands on keyboard, but it kept up fine. My current performance complaints are: startup time, big files (especially big files with highlighting), selecting large blocks of text (spanning more than a screen), and probably some other things I can't think of right now. Some of the plugins are buggy and prone to screwing up more than just the thing they're supposed to changing, but that's not performance-related. Just immature code that's expected of new-ish projects.
- elsurudo 10y ago
  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.
  - hartator 10y ago
    Sublime has also cross-platform. However, Atom.io is very easy to modify. I was able to do 1 or 2 PRs on the code base without any big issues.
  - bastawhiz 10y ago
    It's actually built on Electron, which is their own from-scratch version of NW. JavaScript is very fast, though, and there's really not a way of rendering arbitrary content as well as a browser. The ability to take contributions from the community is much better, as well. Far more people can competently write JavaScript (or with Atom, coffeescript) than C++.
    - skykooler 10y ago
      But, it's not abitrary content. It's text. And we've had good text rendering engines for decades.
      - majewsky 10y ago
        And then you want a popup with a progress bar. Where's your text rendering engine now?
        deleted 10y ago
        [deleted]
        flukus 10y ago
        You launch a popup with whatever GUI toolkit you're using, just like every other application. We had popups with progress bars before computers had GUI's at all.
- zeveb 10y ago
  > It's impressive how Sublime perform well despite having so many advanced features. Does it have any features which emacs — which outperforms it — lacks?
  - hartator 10y ago
    Multi cursors that allow notably powerful column editing will be the main one. For example, it might be the very best - and fun - interactive way to transform a weird CSV in a regular JS array or anything else.
    - jorams 10y ago
      There's an emacs package for that[1]. It's not as well integrated and there are some rough edges, but it's incredibly useful. I use it a lot. Often for quick local refactoring, but also for larger things like you mentioned. [1]: https://github.com/magnars/multiple-cursors.el https://github.com/magnars/multiple-cursors.el
    - zeveb 10y ago
      There's https://github.com/magnars/multiple-cursors.el https://github.com/magnars/multiple-cursors.el And also keyboard macros, which are more often used for the use case you mention.
  - JorgeGT 10y ago
    As shown in the test, editing very large files.
    - zeveb 10y ago
      Fair point — although I do edit ½-gigabyte files pretty commonly.
    - josteink 10y ago
      In general, editing large files in Emacs is super-fast. What's NOT super-fast is editing files with super-long lines (it doesn't even have to be a "big" file). For whatever technical reason, that can grind Emacs to a halt. I'd love to see that bug fixed myself.
- lawnchair_larry 10y ago
  That's because writing a text editor in javascript and using an entire web browser instance to host it isn't a sane thing to do. I hope this trend dies soon. The inmates are running the asylum.
- therealdrag0 10y ago
  If only Sublime had debugging/breakpoint functionality :( That's all I use VC Code for.
drinchev 10y ago
Wow didn't know that Sublime is faster than vim ( some cases ). I'm always surprised by how sublime handles big files, but would've never imagined that it's faster than vim.
Ianvdl 10y ago
Vim performance for large replace operations might be improved by enabling lazy redraw.
- ploxiln 10y ago
  The big problem vim has in this particular test case is the XML. Vim syntax highlighting of XML is significantly slower than other syntaxes. I disable it for XML in my vimrc. A large C or json file would be a good test case to add. (Also, as someone else mentioned, the 3GB file also had rather long lines, some of these editors that failed on that file can handle 3GB files with ~100 character lines.)
SwellJoe 10y ago
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.
- nikcub 10y ago
  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.
  - linkregister 10y ago
    It misses the : operator, which makes it impossible to do a :wq . Or rather the : operator brings up the VS code console which is completely different.
    - mblood 10y ago
      The vscode-vim extension does support the : operator, as well as :wq.
      - nikcub 10y ago
octref 10y ago
What's the point of perf comparison for editors totally not comparable feature-wise?
- crazygringo 10y ago
  What's the point of feature comparison for editors that aren't comparable perf-wise?
- wrsh07 10y ago
  Perf is a feature; so it seems like a comparison of a single (sometimes important) feature irrespective of the other features.
- deleted 10y ago
  [deleted]
- SwellJoe 10y ago
  Features are intended to save time, right? So...is an infinitely featureful editor best, if it also takes infinite time to complete operations? I know this is an absurd extremity; just trying to make a point that features that end up taking longer to "do the thing" than a faster editor with fewer features could do the same thing, aren't providing greater utility than the less featured editor. Note, I'm not saying that the more featureful editors aren't worth the trade off in performance. Just that there is a point where it wouldn't be a good trade. I use both Atom and VS Code (trying to figure out which I like better) for my more complex projects (a lot of files/deps/etc) that I can test locally. But, fall back to vim for quick changes on single files and whenever I'm testing-editing-committing on a remote machine or VM. It's a feature that vim starts instantly, wherever I am. It's a feature that it's still fast(ish) even over a slow(ish) network. A killer features in this case...I can't use Atom or VS Code, at all, on a remote server over a slow link. Literally impossible to do. So, why not compare a bunch of different editors with wildly different capabilities, if it provides insight into the relative performance and sizes of the editors? And, to be fair, some of the fast/light editors are roughly as capable as VS Code, Atom, or Sublime. vim and Emacs are plenty powerful editors with huge ecosystems of additional functionality. I understand the appeal of a good GUI, and the bigger/slower editors do have superior UI to vim or emacs, but it's just one feature of many we can compare.
arca_vorago 10y ago
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)
- problems 10y ago
  I think emacs in practice would give different results than this as you'd typically use it with server mode. 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.
  - throwanem 10y ago
    Not that different; Emacs without complex ~/.emacs.d/init.el loads quite quickly (in unscientific testing on my dev VM with a cold cache, 214ms for "emacs -nw -Q -e 'kill-emacs'").
- microcolonel 10y ago
  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.
  - swah 10y ago
    Some people have been configuring their emacs for 20 years. They don't work in the same level as you - don't just write off as bloaty config :P Its actually awesome - I only stopped because my wrists..
misiti3780 10y ago
I love atom, but those numbers are really bad ...
rawoke083600 10y ago
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
- microcolonel 10y ago
  Geany uses Scintilla, which is what is used by Notepad++, so it should roughly the same.
  - asdfgadsfgasfdg 10y ago
    Except that Notepad++ is running in wine - which much as I think wine is awesome is not perfect. You don't know if a pathological case (e.g. the result for Rehighlight test) is Notepad++ or wine.
    - microcolonel 10y ago
      Wine is often faster than Windows. Some things that require a context switch on Windows are executed in-process on Wine. Everything else is userspace load. There's no reason why the same code on the same processor running in a straight line would perform any differently.
      - asdfgadsfgasfdg 10y ago
        In general yes. I did mention that I think wine is awesome. But it has bugs and the windows APIs it translates are tricky. I assume that the behavior in the re-highlight test is due to a bug. We don't know if this is due to bug in wine or a bug in notepad++.
- Fuzzwah 10y ago
  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.
enraged_camel 10y ago
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.
- problems 10y ago
  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.
JoshGlazebrook 10y ago
With all of the trumpeting of VSCode being so much better than Atom, it sure doesn't hold up with these comparisons. But feature wise, it's still way ahead of Atom.
- revelation 10y ago
  Did we look at the same results here? Atom has memory balloon when loading test.xml without highlighting, takes 4x as long as Code to rehighlight, simple search and replace basically doesn't terminate. They are both terrible but at least Code doesn't seem to hit any degenerate cases.
  - deleted 10y ago
    [deleted]
- equasar 10y ago
  I tried to rerun some of the benchmarks where vscode claimed to be so bad, Couldn't reproduce it, for instance, the replace with regular expression and inserting the "'<!--'" , those were < 1s or almost instantly. I used latest version of VSCode tho. TBH this benchmark is not fair for editors that have constant updates like VSCode and Atom, unless they keep up to date the results.
  - tills13 10y ago
    They used VSCode 1.4 for the tests - the latest stable version is 1.10. Could that be the issue?
    - jhallenworld 10y ago
      Yes, it appears that VSCode is actively being improved, check out: https://code.visualstudio.com/blogs/2017/02/08/syntax-highlighting-optimizations https://code.visualstudio.com/blogs/2017/02/08/syntax-highli...
- satysin 10y ago
  This comparison is from 8 months ago. VSCode has had several big releases since then.
geodel 10y ago
Despite some terrible performance I believe Atom will keep doing fine for reasons I heard: FOSS 1000s (millions?) of plugins RAM/hardware is cheap e.g it works fine on latest generation top of the line hardware. No one should need files more than couple of thousand lines long.
- LanceH 10y ago
  I rarely need to edit a large file. When I do, I just use a different editor. Commit messages load up painfully slowly, however. Again, I just use a different editor, but I would love to hear any fixes for this (tried many).
  - jjuel 10y ago
    So why wouldn't you just always use a different editor? Then you would never have to just load up a different editor you know?
    - bronson 10y ago
      Presumably the different editor is less pleasant to use.
  - deleted 10y ago
    [deleted]
  - deleted 10y ago
    [deleted]
- ksherlock 10y ago
  People said that about Emacs, too (Eight Megs and Constantly Swapping!). And in 10 years, when hardware has finally caught up to the point that atom (A Terabyte of Memory?) has almost acceptable performance, it will be all but abandoned in favor of an even slower and more resource intensive text editor.
  - geodel 10y ago
shalabhc 10y ago
Just here to plug an up-and-coming editor called Howl: https://howl.io https://howl.io 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
- microcolonel 10y ago
  Is there a terminal frontend for howl? It looks like LuaJIT emacs (or I guess more like ymacs) which is potentially interesting.
  - shalabhc 10y ago
    There is no terminal frontend. Yes 'LuaJIT emacs' with a nice API is probably a good description. It does have a vi editing mode as well.
- pawadu 10y ago
  Thanks for posting this! I find Lua much more pleasant than Lisp. It is also performs significantly better. This could result in a very nice editor if enough people embrace it. Github page for the lazy: https://github.com/howl-editor/howl https://github.com/howl-editor/howl
  - shalabhc 10y ago
    Yes I find Howl so much better than the elisp and emacs archaic API.
- deleted 10y ago
  [deleted]
tracker1 10y ago
While nice to know... I'd still prefer VS Code for my day to day usage... even at ~400mb of ram used. The workflow is just nicer, and for most files I would ever touch (well under 100kb), not a big issue. If I ever need something larger than that, odds are I'm using an editor geared towards larger files... different experience for different situations.
- pawadu 10y ago
  Not sure why this is downvoted. vscode works very very well for doing what it was intended for. I love using it for web and golang projects. If my work required me to edit 3GB files however I would use something else, probably not a generic text editor.
diziet 10y ago
Whenever I sit down to help someone on the team that uses Atom, I am always frustrated with the performance of Atom, even compared to Sublime Text. Granted, I am always cognizant and sensitive of these small differences, but it feels as unacceptable as working on a laggy, malware infected computer.
- BinaryIdiot 10y ago
  Not sure what kind of computers you're using. Atom has a slower than most start-up speed and occasionally file opening speed but beyond that it's very fast without lag / latency. Most of the editors inside of an electron shell have slow start-up and file opening times but everything else should be pretty quick.
  - jjuel 10y ago
    Isn't that the point of an editor? That I don't have to use a bulky machine just to run it. If I have to run a machine with 16GB of ram to run the editor I am better of just running a full fledged IDE.
    - BinaryIdiot 10y ago
      I'm not sure I follow. You don't need a "bulky machine" to run a web application inside of an electron shell. They're pretty quick. Sure they use more memory and have a slower start-up time but it's not that bad. I run VSCode on a base level MacBook Air from at least 5 years ago (I think it was the 2nd generation?). My previous PC laptop that was about 8 years old also ran VSCode fine. My point is that some aspects of it, typically ones you do once or a small amount of times, are the points in which it is slow. The performance after those points isn't bad and I've never seen laggy or sluggish scrolling or text input (or at least I hadn't noticed it).
artursapek 10y ago
Oh boy, atom hate thread!
revelation 10y ago
Honestly for editors like Code or Atom, working with large files or huge XML is more of a niche feature. What I care about in editor performance is responsiveness, entering characters and having them show up correctly colored on the display. Or navigating with keyboard shortcuts. Unfortunately this doesn't measure this basic "redraw" performance.
- MichaelGG 10y ago
  VSCode on an Xubuntu 16 VM (VMWare Workstation on Windows 8.1) on a 5th gen i5 with lots of RAM seems very slow to draw. Even the menus are visibly slow. I was disappointed as I thought this might be a quick and easy way to get vim bindings + Rust editing. Maximized, it's even worse - typing is very slow. But that's apparently some sort of bug.
  - tills13 10y ago
    Similar hardware (not running in a VM), none of the performance issues you mention here...
  - steveklabnik 10y ago
    I use this setup on a Windows machine, not a VM. Works very fine here.
  - satysin 10y ago
    Sounds more like an issue with h/w acceleration used by Electron when running in a VM.
- keithnz 10y ago
  same, I'm happy to have multiple editors available for different tasks, use code to code a bunch of things, I'd start worrying if I had HUGE files. big files I rarely need to open in an editor, often I just need to extract something out, in which case I use grep.
xutopia 10y ago
I once had a friend who closed all apps he wasn't using at the time so his memory usage was always below 40%. I told him this was ridiculous to purchase a computer he was only using so little off. I don't care how much memory a text editor uses so long as it does what I need.
- ArlenBales 10y ago
  I can understand leaving some background processes, but why leave open apps you aren't using? It's a bad habit. It's not just memory but also CPU cycles and battery life. Take my mother's iPhone 6; her phone runs slow much of the time because she doesn't care to close out apps she's not using. When I take her phone there's probably 20 apps running eating away battery life and performance.
  - fauigerzigerk 10y ago
    I haven't noticed any effect on battery usage or performance from closing iOS apps. The OS seems to manage that just fine on its own. I have completely stopped closing apps.
  - mbel 10y ago
    This is not how iOS works. Only few apps work ("eat away battery life and performance") in the background, and only in some special circumstances (active music playback, background refresh once in a while if user allows for it). The apps seen it app switcher (double home press) are effectively dead, their state is kept around to allow user to switch back, but they cannot do any processing in background.
- wongarsu 10y ago
  For the same reasons I like editors that use less RAM. I leave all kinds of stuff open all the time because that's more convenient, meaning eventually I run out of RAM no matter how much I have. If an editor takes a gigabyte of ram, that means it's one of the first things I'll close because it's the largest gain. If instead the same editor would only use 100mb of ram, it could stay open indefinitely and I would close a few browser tabs instead.
sigzero 10y ago
jEdit just released 5.4.0, so I am not sure why 5.1 was used instead of 5.3. Interesting though.
- pawadu 10y ago
  He also uses ubuntu 14.04 which probably also means a really old JRE
eugenekolo2 10y ago
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.
- lghh 10y ago
  Are you using a low-power computer? It's slower, but I've never really had an issue with it feeling slow in a way that I noticed.
  - eugenekolo2 10y ago
    I use a $700 Dell on Ubuntu. Fairly decent for the price. But, it's not a Macbook Pro.
  - CyberDildonics 10y ago
    For editing text, everything these days should be considered a high power computer. When a text editor is unusable on a computer that is at least 10,000x as fast as old computers that could edit text just fine, it is time to take a giant step back.
r0bfelty 10y ago
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.
- ursus_bonum 10y ago
  Me too. vim -u NONE is a life saver. /me waits for someone to say we shouldn't have 3GB xml files in the first place, like I don't know that already.
  - i336_ 10y ago
    shrugs just edit them with regular expressions from the commandline. http://stackoverflow.com/a/1732454/3229684 http://stackoverflow.com/a/1732454/3229684
- ploxiln 10y ago
  Or a few other cases of large files, e.g. huge c files (like the sqlite3 amalgamation). Vim's xml syntax highlighting in particular is very slow, but other C-like languages are fine.
aphextron 10y ago
I simply cannot understand why Atom and VSCode are so popular. I get that they are extensible, but so is Sublime. Is that seriously worth a >10x slow down to you?
- tills13 10y ago
  Have you tried either? Or are you just saying that based on what you read in the post?
- tinza123 10y ago
  The benchmark talks about "load time" and "jump to the end" in practice you only need to do that once, and the editor is only rendering the current visible portion of the code. So the relative slow down is more than acceptable. Plus the experience is just so much richer. Sure some editor is quick to do things, but with richer APIs / functionality, developer's time saved is way more important than the several milliseconds of machine time saved.
- equasar 10y ago
  Unless you are using a pretty crippled computer to work on, then yes, you may not need VSCode/Atom. Otherwise I don't see an issue here. everything is about choice. These benchmarks on a modern i3/i5 processors and with 8GB of ram, which is almost the standard now, wont give those slow numbers published. also, I'm pretty sure VSCode at least have gained way more performance that you wouldn't notice these "lags".
  - aphextron 10y ago
    >These benchmarks on a modern i3/i5 processors and with 8GB of ram, which is almost the standard now, wont give those slow numbers published. I don't think that's true at all. My personal experience using both VSCode and Atom on my i7-6700k/16GB work machine has mirrored these results. Files over 30-40k lines simply crash the program.
    - equasar 10y ago
      Maybe sending those crash reports might help you to get them fixed, pretty sure next release (early April) would get fixed. Or if you use insiders build, could get fixed sooner.
aeturnum 10y ago
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.
- cheald 10y ago
  Seconded. It hits the sweet spot of "incredible featureset" and "fast enough that it doesn't get in my way".
- jjuel 10y ago
  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).
  - lucideer 10y ago
    Code is not a fast editor, and you're right that this is likely linked to Electron, but I do think lumping it in with Atom is possibly turning many off it too quickly. The gap in performance between Atom and Code is phenomenal. It's also worth remarking on that some of the treatment of these two in this article is a little odd. Atom is excluded from a lot of tests completely, and Code is particularly penalised in one test for incomplete highlighting (where it's noted it completely the functional task "quickly").
    - oblio 10y ago
      > Atom is excluded from a lot of tests completely I don't know the author's exact methodology, but it's possible that Atom just blew up for some tests, especially the bigger ones.
  - aeturnum 10y ago
dmit 10y ago
See also this post about text editor typing latency: https://pavelfatin.com/typing-with-pleasure/ https://pavelfatin.com/typing-with-pleasure/.
- jhallenworld 10y ago
  Interesting, "Typometer" is a neat tool. But what are the results of editors going through terminal emulators?
drewbailey 10y ago
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.
- Philipp__ 10y ago
  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.
  - pawadu 10y ago
    > The worst thing about Emacs is it's default settings You are right, but the default vim is not that great either...
- farresito 10y ago
  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.
  - Lio 10y ago
    That of course depends on how you add your plugins. For example if you use something like vim-plug[1] (amongst many plugin managers) then you can use on-demand loading to make keep start up times lean.
    - farresito 10y ago
      I do use plug, actually. It was more a complain to the fact that the editor does feel a bit sluggish sometimes if you have a few plugins on. I think vimL is a pretty darn slow language (not to say that it's probably one of the worst languages I've ever touched).
- lazyjones 10y ago
Philipp__ 10y ago
If Sublime only went open source... :sigh:
hawski 10y ago
I am slowly preparing comparison on basis of real edits. I want to get most edited files from Linux kernel and prepare edit commands based on diffs. Then run those edit commands on few editors, compare the speed of whole operation and resources usage. But most important thing is how quick is navigating through whole file at random after all edits. Editors using ropes should have fast edits, but may have slow navigation after lots of edits.
rhabarba 10y ago
I'd assume BSD ed would beat GNU ed easily.
- SwellJoe 10y ago
  Why? GNU grep is (historically, not sure about now) much faster than BSD grep. So, why would you assume BSD ed is faster than GNU?
sho_hn 10y ago
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!
- black_knight 10y ago
  Yes, Kate is so friendly! It is not lightning fast, but if you already run the rest of KDE then its not the slowest part of your workflow.
- dhfhduk 10y ago
  I think Kate is sort of underappreciated. I keep going back to it on Linux after using other editors. 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.
  - sho_hn 10y ago
    Yeah, I usually install it on Windows as well. Works just fine, although I don't use Windows extensively.
black_knight 10y ago
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. [0]: http://acme.cat-v.org/ http://acme.cat-v.org/ [1]: https://github.com/9fans/plan9port https://github.com/9fans/plan9port
- acln 10y ago
  It opens a ~190 MB JSON file[0] in about 2 seconds on my machine. Scrolling and jumping around the file feels very smooth. Editing is also crisp. Writing the file back to disk takes about as long as opening it. [0]: https://github.com/zemirco/sf-city-lots-json https://github.com/zemirco/sf-city-lots-json
- EdiX 10y ago
  For test.xml the RSS is 20MB and opening it and going to the last character is instantaneous, search and replace on test.xml takes slightly less than one second.
Semaphor 10y ago
Does the time to open that 3GB file include saving the file? If so, EmEditor (https://www.emeditor.com/ https://www.emeditor.com/ windows only, payware) is way faster (my unscientific test via stopwatch gave me around 3 seconds) ;) It also supports only opening parts of a file (so limiting it to the first 80 kbytes takes the time town to some ms). Sorry if I sound like a shill, but no one seems to know of it and I simply love it's speed.
cgb223 10y ago
> 6 MB Swap Why even bother making a swap partition if its going to be that small
- jhallenworld 10y ago
  Ubuntu created it by default.
icc97 10y ago
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.
- a3n 10y ago
  > 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.
  - deleted 10y ago
    [deleted]
  - icc97 10y ago
    Yes, I'm sure this is true. It's just that it takes a really long time to get all the commands into muscle memory. I've been using Vim for over a decade and still don't feel comfortable doing more than quick edits to individual files. All editors from Notepad to ST / Atom, Browsers and Document editors have the same keys for search, replace, new tab, close tab, new document. But learning vim is a completely different language. I mean that in the sense of actually learning a spoken language. Until you're fluent in it, it's really awkward. My latest step has been finally to get round to using tabs which I'd never even really considered for Vim. But even that requires learning all the new tab commands, there's no Ctrl + Tab and Ctrl + Shift + Tab. I'm in the Windows world which doesn't help with learning Vim as it's just not as pleasant experience as using it in the Linux command prompt.
sdfghs5 10y ago
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 ...).
- bitmapbrother 10y ago
  UltraEdit chokes on large files and I quit using it and moved to using Sublime and Notepadd++.
  - placebo 10y ago
    My experience has been the exact opposite. The latest version of UltraEdit easily handles large files that Notepad++ and Sublime Text 2 choke on. Didn't purchase Sublime Text 3 yet so the situation might be different there.
    - bitmapbrother 10y ago
      I installed the latest version and proceeded to load a 500MB file. The app became unresponsive and any attempt to scroll just froze the app.
enahs-sf 10y ago
This is about what I would expect. I generally develop using sublime. When things get hairy, or on the server, I switch to vim. For the big files, you have to bust out the unix tools to do the heavy lifting.
hackuser 10y ago
> huge 3 GB file (3M 1K lines) I looked into text editors for handing very large files several years ago. For your perusal my results, hopefully not too outdated: [0] . SOME USEFUL SPECS to consider * Performs with %yourmemorycapacity% and %yourdiskthroughput% * Optionally disable features that multiply required memory capacity and disk capacity & throughput: Auto-backup, temp files, auto-conversion to different character encodings (e.g., 8-bit to 16-bit) * Optionally disable parsing of data (for any purpose, from syntax highlighting to structured data) * Load subset of file into memory at any one time * Begin editing before file fully loaded . SOME USEFUL RESOURCES * http://texteditors.org/cgi-bin/wiki.pl?CategoryLargeFileHandling http://texteditors.org/cgi-bin/wiki.pl?CategoryLargeFileHand... * http://www.knudvaneeden.com/links/file/addactivity/computer/editor/if_you_want_to_regularly_work_with_very_large_files_which_microsoft_windows_programmer_text_editor_to_possibly_choose/01/01.htm http://www.knudvaneeden.com/links/file/addactivity/computer/... . SOME USEFUL SOLUTIONS * EmEditor: This was very impressive. The speed is breathtaking for what it does, and it can handle advanced functions such as column operations on the full file with ease. We chose this and users were very happy; it transformed their abilty to work with large text files. ---- These were on our shortlist to test next but we didn't get to them due to available time and EmEditor's fantastic results: * VEDIT: Designed for large files. They charge for it, IIRC, but based on its reputation it is worth the investment. * The Semware Editor (TSE): Also a great reputation * 010 Editor: http://www.sweetscape.com/010editor/ http://www.sweetscape.com/010editor/ * PilotEdit: http://www.pilotedit.com/ http://www.pilotedit.com/ ---- Also of interest: * File Query: Treats file as a database, enabling parsing, queries; very flexible and powerful, per reviews: http://www.agiledatasoftware.com/ http://www.agiledatasoftware.com/ * PDT-Windows: A database editor which reputedly has a max filesize of 18 EB (exabytes) * bvi: Binary VI [0] Some of this is copied from an earlier HN comment of mine
egh 10y ago
It's not clear exactly how this was generated, but emacs ships with a full-featured XML editor as the default XML mode (https://www.emacswiki.org/emacs/NxmlMode https://www.emacswiki.org/emacs/NxmlMode) that includes syntax and schema validation, which probably impact the XML benchmarks.
rl3 10y ago
Can anyone speak to the difference the underlying hardware makes with Atom or Code? Presumably a top-end desktop processor (~4GHz) and latest-generation NVME storage would offer really good performance, but perhaps not. If I had to guess, the average setup is probably a mobile processor paired with a traditional SSD.
- majewsky 10y ago
  A year ago, people made fun about how programs will get proportionally slower once all the developers have switched to SSDs. Now we're already talking about having to upgrade to NVMe disks for a decent code editing experience.
- RaleyField 10y ago
  Take those numbers with reserve. If anything they are 8 months old, RSS is 56 MB for hello.c on my installation of VS Code. I can run VS Code comfortably in VirtualBox on a midrange i5. Edit: Also moving around test.xml doesn't take 22 seconds, it's pretty much instantaneous, although replace is still slow.
davidw 10y ago
Time spent thinking about code and typing it in, one letter at a time: thousands and thousands of hours. Editor performance is never something I've worried about.
legulere 10y ago
VS Code seems extremely responsive to me when in use, but fairly slow to start and exit. I wonder if this makes VS Code look worse than it is in those benchmarks. What I would be interested in would be time from keystroke to screen, scrolling, etc.
Shank 10y ago
This is great and all, but I'd really prefer an updated benchmark on things I do on a minute to minute basis (e.g., time for a keypress to insert a character, time for tabs to switch, etc.) Large file benchmarks are nice, but usually I'm in a sub 1000 line file and it matters more how fast input is across the board.
jimnotgym 10y ago
I was trying a bunch of different editors last year and tried Atom out. I have used it ever since. It just seems nice to use. I am not really seeing the performance issues others are. I use it on a 1st generation i5 laptop with 4GB ram on Ubuntu, and in an Ubuntu VM on Windows 7, so I'm doing alright on low end hardware. When I have to open very large files, it is usually log files on a server and I tend to us grep and tail etc...
HugoDaniel 10y ago
been using nvi for a year now, it's a great editor, glad to see it score so well :)
- bch 10y ago
  You might like my occasional https://twitter.com/search?q=todayInNvi https://twitter.com/search?q=todayInNvi
  - HugoDaniel 10y ago
    ah! really cool, thanks :)
  - HugoDaniel 10y ago
    You have some very good tips there. Unfortunately not all of them have the #todayInNvi. Lets do a simple page with them on it ? :D
    - bch 10y ago
      You're right, they don't. I will collect them together. Glad you enjoyed them!
eddd 10y ago
As a heavy user of Atom I am surprised with the benchmarks. To me the editor is fast enough, can't provide any numbers but it is pretty responsive for daily usage (Python, C, Puppet, Elixir, Erlang)
- danpalmer 10y ago
  I don't use Atom at work because of speed issues - working on a codebase of ~250k lines and it takes quite a while to search/replace, and fuzzy match on file opening. I do use it on personal projects which are much smaller though.
  - pawadu 10y ago
    > codebase of ~250k lines In the same file? Holy crap...
tomcam 10y ago
Performance of mcedit makes it and Midnight Commander the sleepers of the year. Didn't even know there was an mcedit, to be honest.
paule89 10y ago
I like atom just because of the easy plugin management. But it is slow as hell. Would love to use vim or emacs, but I don't want to invest too much time into learning one system. Would want to learn the better one. Too bad notepad++ only runs under wine.
mmel 10y ago
Joe seems quite fast and robust across all the tests.
nine_k 10y ago
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.
- Klathmon 10y ago
  It also missed the mark with many of the others on that list. The line between editor and IDE is getting more blurred every day. I use Atom. It gets opened once a day and closed at the end of the day. It could take minutes to start for all I care. The amount of time saved by having the vast set of plugins, the customization, the tools, and more greatly exceed any kind of savings I'd get from faster startup time. People tell me how I'm wrong because my editor shouldn't use so much memory, I try to tell them that I'm more than happy with the memory usage for what I get and it runs fantastically on my computer. But at the same time, I use nano on remote machines for quick edits all the time. If it were slow to start, it'd be useless. And again if I were using an older PC with 4gb of ram and a 5400RPM HDD I might feel that the performance of atom is an issue, so I'd probably use something else. I'm glad there are so many options that all focus on different workflows and features. Just because one doesn't focus on the workflow you use doesn't make it wrong or worse, just worse for you.
deleted 10y ago
[deleted]
Tomte 10y ago
I love joe. They released an up-to-date Windows binary recently, and I guess we'll get regular Windows releases now.
diroussel 10y ago
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/ https://pavelfatin.com/typing-with-pleasure/
- therealdrag0 10y ago
  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.
greggman 10y ago
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
- agumonkey 10y ago
  Emacs still has quite a lot of energy, people are working on deep levels (core, guilemacs) and the community is handling the userspace part through packages (melpa, etc). There are a few warts in a way compared to the layouting flexibilty of html/css, but beside that, the ability of emacs[-lisp] to absorb any new idea is still very high. Long time ago, when Sublime grabbed a share of the market, there was a 2 hour long video about what ST brought you. I yawned all along. The few things that weren't already in emacs appeared organically in no time; whereas 70% of features were there since the 90s. My view is biased, I'm in a lexicalist period (blame it on sml) where I want a few equations, type constraints etc and no visual flexibility (which I wanted in the past).
  - oblio 10y ago
    His point wasn't that Emacs has fewer features, his point was that many of those features are half-baked compared to the implementation provided by Sublime. You give up a bit of flexibility for more stability and overall polish. That seems like a fair point.
    - 10y ago
d--b 10y ago
When I read the title, I thought this would be about the time it took to write a piece of code in each editor. Yes Visual studio has a ton of overhead, but I doubt I would write code faster using nano...
pawadu 10y ago
So basically emacs is faster than sublime on tests that are not completely made up? So why am I seeing so much praise for sublime here? Also, mg is starting to grow on me. I think it should replace nano and vi as the default unix editors.
Too 10y ago
It would be interesting to know if word wrap is turned on or off. This makes a humongous difference in some editors, especially notepad++. Turn it off and you can easily open 1GB files, turn it on and it will crash on the same file. To make the comparisons fair, the table should also include whether the editor highlights (and indexes) the file using a proper parser instead of just line-by-line regex. More realistic hardware would also be interesting. He doesn't even have SSD...
rsa4046 10y ago
Sorry, late to this party, but Gentoo/Funtoo Linux. Funtoo has git-based portage, simple to install, up and running quickly. Yes, there are still compile times to deal with, but with fast machines these are pretty minimal. I find Funtoo/Gentoo the only distribution I can maintain long term.

330 points by gnuvince 10y ago

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.

andrewclunn 10y ago
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.
- shalabhc 10y ago
  Can you give a ballpark estimate of the sizes of these files?
dan353hehe 10y ago
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.

hartator 10y ago

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.

SwellJoe 10y ago
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.)
- bastawhiz 10y ago
  That's interesting to hear, because I've tried Atom three times now and the biggest deal-breaker every single time has been performance. Around the first release, there was noticeable lag as I typed. About a year later, tabbing through find results was just absurdly slow. More recently, opening a multi-megabyte JSON file with syntax highlighting was an inexcusably painful experience. I really, really want to use and support Atom, but the performance compared to Sublime has just been atrocious (in my experience).
  - SwellJoe 10y ago
    Oh, it's still slow. Pathologically so in some cases. But, so is VS Code. But, Atom's speed has become manageable in recent versions. I rarely find myself unable to work with a big file in Atom. For code, I rarely see files bigger than a few thousand lines (and never produce files that large myself), and Atom handles them OK (not great, but acceptable, given the other benefits of the tool). VS Code is still better, and of course, vim smokes them both. But, there are trade offs, and Atom has a lot of cool features. I wouldn't use it for really large files, however. It really shows its ass in those cases (as the XML file test here shows).
- hartator 10y ago
  My main issue with Atom.io performance is typing lag, it's kind of my main thing for an editor unfortunately. I love Atom.io otherwise.
  - SwellJoe 10y ago
    I don't notice typing lag, anymore. Just now I opened it up and tried to get ahead of it by slamming flat hands on keyboard, but it kept up fine. My current performance complaints are: startup time, big files (especially big files with highlighting), selecting large blocks of text (spanning more than a screen), and probably some other things I can't think of right now. Some of the plugins are buggy and prone to screwing up more than just the thing they're supposed to changing, but that's not performance-related. Just immature code that's expected of new-ish projects.
elsurudo 10y ago
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.
- hartator 10y ago
  Sublime has also cross-platform. However, Atom.io is very easy to modify. I was able to do 1 or 2 PRs on the code base without any big issues.
- bastawhiz 10y ago
  It's actually built on Electron, which is their own from-scratch version of NW. JavaScript is very fast, though, and there's really not a way of rendering arbitrary content as well as a browser. The ability to take contributions from the community is much better, as well. Far more people can competently write JavaScript (or with Atom, coffeescript) than C++.
  - skykooler 10y ago
    But, it's not abitrary content. It's text. And we've had good text rendering engines for decades.
    - majewsky 10y ago
      And then you want a popup with a progress bar. Where's your text rendering engine now?
      - deleted 10y ago
        [deleted]
      - flukus 10y ago
        You launch a popup with whatever GUI toolkit you're using, just like every other application. We had popups with progress bars before computers had GUI's at all.
zeveb 10y ago
> It's impressive how Sublime perform well despite having so many advanced features. Does it have any features which emacs — which outperforms it — lacks?
- hartator 10y ago
  Multi cursors that allow notably powerful column editing will be the main one. For example, it might be the very best - and fun - interactive way to transform a weird CSV in a regular JS array or anything else.
  - jorams 10y ago
    There's an emacs package for that[1]. It's not as well integrated and there are some rough edges, but it's incredibly useful. I use it a lot. Often for quick local refactoring, but also for larger things like you mentioned. [1]: https://github.com/magnars/multiple-cursors.el https://github.com/magnars/multiple-cursors.el
  - zeveb 10y ago
    There's https://github.com/magnars/multiple-cursors.el https://github.com/magnars/multiple-cursors.el And also keyboard macros, which are more often used for the use case you mention.
- JorgeGT 10y ago
  As shown in the test, editing very large files.
  - zeveb 10y ago
    Fair point — although I do edit ½-gigabyte files pretty commonly.
  - josteink 10y ago
    In general, editing large files in Emacs is super-fast. What's NOT super-fast is editing files with super-long lines (it doesn't even have to be a "big" file). For whatever technical reason, that can grind Emacs to a halt. I'd love to see that bug fixed myself.
lawnchair_larry 10y ago
That's because writing a text editor in javascript and using an entire web browser instance to host it isn't a sane thing to do. I hope this trend dies soon. The inmates are running the asylum.
therealdrag0 10y ago
If only Sublime had debugging/breakpoint functionality :( That's all I use VC Code for.

drinchev 10y ago

Wow didn't know that Sublime is faster than vim ( some cases ). I'm always surprised by how sublime handles big files, but would've never imagined that it's faster than vim.

Ianvdl 10y ago

Vim performance for large replace operations might be improved by enabling lazy redraw.

ploxiln 10y ago
The big problem vim has in this particular test case is the XML. Vim syntax highlighting of XML is significantly slower than other syntaxes. I disable it for XML in my vimrc. A large C or json file would be a good test case to add. (Also, as someone else mentioned, the 3GB file also had rather long lines, some of these editors that failed on that file can handle 3GB files with ~100 character lines.)

SwellJoe 10y ago

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.

nikcub 10y ago
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.
- linkregister 10y ago
  It misses the : operator, which makes it impossible to do a :wq . Or rather the : operator brings up the VS code console which is completely different.
  - mblood 10y ago
    The vscode-vim extension does support the : operator, as well as :wq.
    - nikcub 10y ago

octref 10y ago

What's the point of perf comparison for editors totally not comparable feature-wise?

crazygringo 10y ago
What's the point of feature comparison for editors that aren't comparable perf-wise?
wrsh07 10y ago
Perf is a feature; so it seems like a comparison of a single (sometimes important) feature irrespective of the other features.
deleted 10y ago
[deleted]
SwellJoe 10y ago
Features are intended to save time, right? So...is an infinitely featureful editor best, if it also takes infinite time to complete operations? I know this is an absurd extremity; just trying to make a point that features that end up taking longer to "do the thing" than a faster editor with fewer features could do the same thing, aren't providing greater utility than the less featured editor. Note, I'm not saying that the more featureful editors aren't worth the trade off in performance. Just that there is a point where it wouldn't be a good trade. I use both Atom and VS Code (trying to figure out which I like better) for my more complex projects (a lot of files/deps/etc) that I can test locally. But, fall back to vim for quick changes on single files and whenever I'm testing-editing-committing on a remote machine or VM. It's a feature that vim starts instantly, wherever I am. It's a feature that it's still fast(ish) even over a slow(ish) network. A killer features in this case...I can't use Atom or VS Code, at all, on a remote server over a slow link. Literally impossible to do. So, why not compare a bunch of different editors with wildly different capabilities, if it provides insight into the relative performance and sizes of the editors? And, to be fair, some of the fast/light editors are roughly as capable as VS Code, Atom, or Sublime. vim and Emacs are plenty powerful editors with huge ecosystems of additional functionality. I understand the appeal of a good GUI, and the bigger/slower editors do have superior UI to vim or emacs, but it's just one feature of many we can compare.

arca_vorago 10y ago

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)

problems 10y ago
I think emacs in practice would give different results than this as you'd typically use it with server mode. 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.
- throwanem 10y ago
  Not that different; Emacs without complex ~/.emacs.d/init.el loads quite quickly (in unscientific testing on my dev VM with a cold cache, 214ms for "emacs -nw -Q -e 'kill-emacs'").
microcolonel 10y ago
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.
- swah 10y ago
  Some people have been configuring their emacs for 20 years. They don't work in the same level as you - don't just write off as bloaty config :P Its actually awesome - I only stopped because my wrists..

misiti3780 10y ago

I love atom, but those numbers are really bad ...

rawoke083600 10y ago

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

microcolonel 10y ago
Geany uses Scintilla, which is what is used by Notepad++, so it should roughly the same.
- asdfgadsfgasfdg 10y ago
  Except that Notepad++ is running in wine - which much as I think wine is awesome is not perfect. You don't know if a pathological case (e.g. the result for Rehighlight test) is Notepad++ or wine.
  - microcolonel 10y ago
    Wine is often faster than Windows. Some things that require a context switch on Windows are executed in-process on Wine. Everything else is userspace load. There's no reason why the same code on the same processor running in a straight line would perform any differently.
    - asdfgadsfgasfdg 10y ago
      In general yes. I did mention that I think wine is awesome. But it has bugs and the windows APIs it translates are tricky. I assume that the behavior in the re-highlight test is due to a bug. We don't know if this is due to bug in wine or a bug in notepad++.
Fuzzwah 10y ago
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.

enraged_camel 10y ago

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.

problems 10y ago
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.

JoshGlazebrook 10y ago

With all of the trumpeting of VSCode being so much better than Atom, it sure doesn't hold up with these comparisons. But feature wise, it's still way ahead of Atom.

revelation 10y ago
Did we look at the same results here? Atom has memory balloon when loading test.xml without highlighting, takes 4x as long as Code to rehighlight, simple search and replace basically doesn't terminate. They are both terrible but at least Code doesn't seem to hit any degenerate cases.
- deleted 10y ago
  [deleted]
equasar 10y ago
I tried to rerun some of the benchmarks where vscode claimed to be so bad, Couldn't reproduce it, for instance, the replace with regular expression and inserting the "'<!--'" , those were < 1s or almost instantly. I used latest version of VSCode tho. TBH this benchmark is not fair for editors that have constant updates like VSCode and Atom, unless they keep up to date the results.
- tills13 10y ago
  They used VSCode 1.4 for the tests - the latest stable version is 1.10. Could that be the issue?
  - jhallenworld 10y ago
    Yes, it appears that VSCode is actively being improved, check out: https://code.visualstudio.com/blogs/2017/02/08/syntax-highlighting-optimizations https://code.visualstudio.com/blogs/2017/02/08/syntax-highli...
satysin 10y ago
This comparison is from 8 months ago. VSCode has had several big releases since then.

geodel 10y ago

Despite some terrible performance I believe Atom will keep doing fine for reasons I heard: FOSS 1000s (millions?) of plugins RAM/hardware is cheap e.g it works fine on latest generation top of the line hardware. No one should need files more than couple of thousand lines long.

LanceH 10y ago
I rarely need to edit a large file. When I do, I just use a different editor. Commit messages load up painfully slowly, however. Again, I just use a different editor, but I would love to hear any fixes for this (tried many).
- jjuel 10y ago
  So why wouldn't you just always use a different editor? Then you would never have to just load up a different editor you know?
  - bronson 10y ago
    Presumably the different editor is less pleasant to use.
- deleted 10y ago
  [deleted]
- deleted 10y ago
  [deleted]
ksherlock 10y ago
People said that about Emacs, too (Eight Megs and Constantly Swapping!). And in 10 years, when hardware has finally caught up to the point that atom (A Terabyte of Memory?) has almost acceptable performance, it will be all but abandoned in favor of an even slower and more resource intensive text editor.
- geodel 10y ago

shalabhc 10y ago

Just here to plug an up-and-coming editor called Howl: https://howl.io https://howl.io 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

microcolonel 10y ago
Is there a terminal frontend for howl? It looks like LuaJIT emacs (or I guess more like ymacs) which is potentially interesting.
- shalabhc 10y ago
  There is no terminal frontend. Yes 'LuaJIT emacs' with a nice API is probably a good description. It does have a vi editing mode as well.
pawadu 10y ago
Thanks for posting this! I find Lua much more pleasant than Lisp. It is also performs significantly better. This could result in a very nice editor if enough people embrace it. Github page for the lazy: https://github.com/howl-editor/howl https://github.com/howl-editor/howl
- shalabhc 10y ago
  Yes I find Howl so much better than the elisp and emacs archaic API.
deleted 10y ago
[deleted]

tracker1 10y ago

While nice to know... I'd still prefer VS Code for my day to day usage... even at ~400mb of ram used. The workflow is just nicer, and for most files I would ever touch (well under 100kb), not a big issue. If I ever need something larger than that, odds are I'm using an editor geared towards larger files... different experience for different situations.

pawadu 10y ago
Not sure why this is downvoted. vscode works very very well for doing what it was intended for. I love using it for web and golang projects. If my work required me to edit 3GB files however I would use something else, probably not a generic text editor.

diziet 10y ago

Whenever I sit down to help someone on the team that uses Atom, I am always frustrated with the performance of Atom, even compared to Sublime Text. Granted, I am always cognizant and sensitive of these small differences, but it feels as unacceptable as working on a laggy, malware infected computer.

BinaryIdiot 10y ago
Not sure what kind of computers you're using. Atom has a slower than most start-up speed and occasionally file opening speed but beyond that it's very fast without lag / latency. Most of the editors inside of an electron shell have slow start-up and file opening times but everything else should be pretty quick.
- jjuel 10y ago
  Isn't that the point of an editor? That I don't have to use a bulky machine just to run it. If I have to run a machine with 16GB of ram to run the editor I am better of just running a full fledged IDE.
  - BinaryIdiot 10y ago
    I'm not sure I follow. You don't need a "bulky machine" to run a web application inside of an electron shell. They're pretty quick. Sure they use more memory and have a slower start-up time but it's not that bad. I run VSCode on a base level MacBook Air from at least 5 years ago (I think it was the 2nd generation?). My previous PC laptop that was about 8 years old also ran VSCode fine. My point is that some aspects of it, typically ones you do once or a small amount of times, are the points in which it is slow. The performance after those points isn't bad and I've never seen laggy or sluggish scrolling or text input (or at least I hadn't noticed it).

artursapek 10y ago

Oh boy, atom hate thread!

revelation 10y ago

Honestly for editors like Code or Atom, working with large files or huge XML is more of a niche feature. What I care about in editor performance is responsiveness, entering characters and having them show up correctly colored on the display. Or navigating with keyboard shortcuts. Unfortunately this doesn't measure this basic "redraw" performance.

MichaelGG 10y ago
VSCode on an Xubuntu 16 VM (VMWare Workstation on Windows 8.1) on a 5th gen i5 with lots of RAM seems very slow to draw. Even the menus are visibly slow. I was disappointed as I thought this might be a quick and easy way to get vim bindings + Rust editing. Maximized, it's even worse - typing is very slow. But that's apparently some sort of bug.
- tills13 10y ago
  Similar hardware (not running in a VM), none of the performance issues you mention here...
- steveklabnik 10y ago
  I use this setup on a Windows machine, not a VM. Works very fine here.
- satysin 10y ago
  Sounds more like an issue with h/w acceleration used by Electron when running in a VM.
keithnz 10y ago
same, I'm happy to have multiple editors available for different tasks, use code to code a bunch of things, I'd start worrying if I had HUGE files. big files I rarely need to open in an editor, often I just need to extract something out, in which case I use grep.

xutopia 10y ago

I once had a friend who closed all apps he wasn't using at the time so his memory usage was always below 40%. I told him this was ridiculous to purchase a computer he was only using so little off. I don't care how much memory a text editor uses so long as it does what I need.

ArlenBales 10y ago
I can understand leaving some background processes, but why leave open apps you aren't using? It's a bad habit. It's not just memory but also CPU cycles and battery life. Take my mother's iPhone 6; her phone runs slow much of the time because she doesn't care to close out apps she's not using. When I take her phone there's probably 20 apps running eating away battery life and performance.
- fauigerzigerk 10y ago
  I haven't noticed any effect on battery usage or performance from closing iOS apps. The OS seems to manage that just fine on its own. I have completely stopped closing apps.
- mbel 10y ago
  This is not how iOS works. Only few apps work ("eat away battery life and performance") in the background, and only in some special circumstances (active music playback, background refresh once in a while if user allows for it). The apps seen it app switcher (double home press) are effectively dead, their state is kept around to allow user to switch back, but they cannot do any processing in background.
wongarsu 10y ago
For the same reasons I like editors that use less RAM. I leave all kinds of stuff open all the time because that's more convenient, meaning eventually I run out of RAM no matter how much I have. If an editor takes a gigabyte of ram, that means it's one of the first things I'll close because it's the largest gain. If instead the same editor would only use 100mb of ram, it could stay open indefinitely and I would close a few browser tabs instead.

sigzero 10y ago

jEdit just released 5.4.0, so I am not sure why 5.1 was used instead of 5.3. Interesting though.

pawadu 10y ago
He also uses ubuntu 14.04 which probably also means a really old JRE

eugenekolo2 10y ago

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.

lghh 10y ago
Are you using a low-power computer? It's slower, but I've never really had an issue with it feeling slow in a way that I noticed.
- eugenekolo2 10y ago
  I use a $700 Dell on Ubuntu. Fairly decent for the price. But, it's not a Macbook Pro.
- CyberDildonics 10y ago
  For editing text, everything these days should be considered a high power computer. When a text editor is unusable on a computer that is at least 10,000x as fast as old computers that could edit text just fine, it is time to take a giant step back.

r0bfelty 10y ago

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.

ursus_bonum 10y ago
Me too. vim -u NONE is a life saver. /me waits for someone to say we shouldn't have 3GB xml files in the first place, like I don't know that already.
- i336_ 10y ago
  shrugs just edit them with regular expressions from the commandline. http://stackoverflow.com/a/1732454/3229684 http://stackoverflow.com/a/1732454/3229684
ploxiln 10y ago
Or a few other cases of large files, e.g. huge c files (like the sqlite3 amalgamation). Vim's xml syntax highlighting in particular is very slow, but other C-like languages are fine.

aphextron 10y ago

I simply cannot understand why Atom and VSCode are so popular. I get that they are extensible, but so is Sublime. Is that seriously worth a >10x slow down to you?

tills13 10y ago
Have you tried either? Or are you just saying that based on what you read in the post?
tinza123 10y ago
The benchmark talks about "load time" and "jump to the end" in practice you only need to do that once, and the editor is only rendering the current visible portion of the code. So the relative slow down is more than acceptable. Plus the experience is just so much richer. Sure some editor is quick to do things, but with richer APIs / functionality, developer's time saved is way more important than the several milliseconds of machine time saved.
equasar 10y ago
Unless you are using a pretty crippled computer to work on, then yes, you may not need VSCode/Atom. Otherwise I don't see an issue here. everything is about choice. These benchmarks on a modern i3/i5 processors and with 8GB of ram, which is almost the standard now, wont give those slow numbers published. also, I'm pretty sure VSCode at least have gained way more performance that you wouldn't notice these "lags".
- aphextron 10y ago
  >These benchmarks on a modern i3/i5 processors and with 8GB of ram, which is almost the standard now, wont give those slow numbers published. I don't think that's true at all. My personal experience using both VSCode and Atom on my i7-6700k/16GB work machine has mirrored these results. Files over 30-40k lines simply crash the program.
  - equasar 10y ago
    Maybe sending those crash reports might help you to get them fixed, pretty sure next release (early April) would get fixed. Or if you use insiders build, could get fixed sooner.

aeturnum 10y ago

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.

cheald 10y ago
Seconded. It hits the sweet spot of "incredible featureset" and "fast enough that it doesn't get in my way".
jjuel 10y ago
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).
- lucideer 10y ago
  Code is not a fast editor, and you're right that this is likely linked to Electron, but I do think lumping it in with Atom is possibly turning many off it too quickly. The gap in performance between Atom and Code is phenomenal. It's also worth remarking on that some of the treatment of these two in this article is a little odd. Atom is excluded from a lot of tests completely, and Code is particularly penalised in one test for incomplete highlighting (where it's noted it completely the functional task "quickly").
  - oblio 10y ago
    > Atom is excluded from a lot of tests completely I don't know the author's exact methodology, but it's possible that Atom just blew up for some tests, especially the bigger ones.
- aeturnum 10y ago

dmit 10y ago

See also this post about text editor typing latency: https://pavelfatin.com/typing-with-pleasure/ https://pavelfatin.com/typing-with-pleasure/.

jhallenworld 10y ago
Interesting, "Typometer" is a neat tool. But what are the results of editors going through terminal emulators?

drewbailey 10y ago

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.

Philipp__ 10y ago
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.
- pawadu 10y ago
  > The worst thing about Emacs is it's default settings You are right, but the default vim is not that great either...
farresito 10y ago
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.
- Lio 10y ago
  That of course depends on how you add your plugins. For example if you use something like vim-plug[1] (amongst many plugin managers) then you can use on-demand loading to make keep start up times lean.
  - farresito 10y ago
    I do use plug, actually. It was more a complain to the fact that the editor does feel a bit sluggish sometimes if you have a few plugins on. I think vimL is a pretty darn slow language (not to say that it's probably one of the worst languages I've ever touched).
lazyjones 10y ago

Philipp__ 10y ago

If Sublime only went open source... :sigh:

hawski 10y ago

I am slowly preparing comparison on basis of real edits. I want to get most edited files from Linux kernel and prepare edit commands based on diffs. Then run those edit commands on few editors, compare the speed of whole operation and resources usage. But most important thing is how quick is navigating through whole file at random after all edits. Editors using ropes should have fast edits, but may have slow navigation after lots of edits.

rhabarba 10y ago

I'd assume BSD ed would beat GNU ed easily.

SwellJoe 10y ago
Why? GNU grep is (historically, not sure about now) much faster than BSD grep. So, why would you assume BSD ed is faster than GNU?

sho_hn 10y ago

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!

black_knight 10y ago
Yes, Kate is so friendly! It is not lightning fast, but if you already run the rest of KDE then its not the slowest part of your workflow.
dhfhduk 10y ago
I think Kate is sort of underappreciated. I keep going back to it on Linux after using other editors. 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.
- sho_hn 10y ago
  Yeah, I usually install it on Windows as well. Works just fine, although I don't use Windows extensively.

black_knight 10y ago

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. [0]: http://acme.cat-v.org/ http://acme.cat-v.org/ [1]: https://github.com/9fans/plan9port https://github.com/9fans/plan9port

acln 10y ago
It opens a ~190 MB JSON file[0] in about 2 seconds on my machine. Scrolling and jumping around the file feels very smooth. Editing is also crisp. Writing the file back to disk takes about as long as opening it. [0]: https://github.com/zemirco/sf-city-lots-json https://github.com/zemirco/sf-city-lots-json
EdiX 10y ago
For test.xml the RSS is 20MB and opening it and going to the last character is instantaneous, search and replace on test.xml takes slightly less than one second.

Semaphor 10y ago

Does the time to open that 3GB file include saving the file? If so, EmEditor (https://www.emeditor.com/ https://www.emeditor.com/ windows only, payware) is way faster (my unscientific test via stopwatch gave me around 3 seconds) ;) It also supports only opening parts of a file (so limiting it to the first 80 kbytes takes the time town to some ms). Sorry if I sound like a shill, but no one seems to know of it and I simply love it's speed.

cgb223 10y ago

> 6 MB Swap Why even bother making a swap partition if its going to be that small

jhallenworld 10y ago
Ubuntu created it by default.

icc97 10y ago

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.

a3n 10y ago
> 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.
- deleted 10y ago
  [deleted]
- icc97 10y ago
  Yes, I'm sure this is true. It's just that it takes a really long time to get all the commands into muscle memory. I've been using Vim for over a decade and still don't feel comfortable doing more than quick edits to individual files. All editors from Notepad to ST / Atom, Browsers and Document editors have the same keys for search, replace, new tab, close tab, new document. But learning vim is a completely different language. I mean that in the sense of actually learning a spoken language. Until you're fluent in it, it's really awkward. My latest step has been finally to get round to using tabs which I'd never even really considered for Vim. But even that requires learning all the new tab commands, there's no Ctrl + Tab and Ctrl + Shift + Tab. I'm in the Windows world which doesn't help with learning Vim as it's just not as pleasant experience as using it in the Linux command prompt.

sdfghs5 10y ago

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 ...).

bitmapbrother 10y ago
UltraEdit chokes on large files and I quit using it and moved to using Sublime and Notepadd++.
- placebo 10y ago
  My experience has been the exact opposite. The latest version of UltraEdit easily handles large files that Notepad++ and Sublime Text 2 choke on. Didn't purchase Sublime Text 3 yet so the situation might be different there.
  - bitmapbrother 10y ago
    I installed the latest version and proceeded to load a 500MB file. The app became unresponsive and any attempt to scroll just froze the app.

enahs-sf 10y ago

This is about what I would expect. I generally develop using sublime. When things get hairy, or on the server, I switch to vim. For the big files, you have to bust out the unix tools to do the heavy lifting.

hackuser 10y ago

> huge 3 GB file (3M 1K lines) I looked into text editors for handing very large files several years ago. For your perusal my results, hopefully not too outdated: [0] . SOME USEFUL SPECS to consider * Performs with %yourmemorycapacity% and %yourdiskthroughput% * Optionally disable features that multiply required memory capacity and disk capacity & throughput: Auto-backup, temp files, auto-conversion to different character encodings (e.g., 8-bit to 16-bit) * Optionally disable parsing of data (for any purpose, from syntax highlighting to structured data) * Load subset of file into memory at any one time * Begin editing before file fully loaded . SOME USEFUL RESOURCES * http://texteditors.org/cgi-bin/wiki.pl?CategoryLargeFileHandling http://texteditors.org/cgi-bin/wiki.pl?CategoryLargeFileHand... * http://www.knudvaneeden.com/links/file/addactivity/computer/editor/if_you_want_to_regularly_work_with_very_large_files_which_microsoft_windows_programmer_text_editor_to_possibly_choose/01/01.htm http://www.knudvaneeden.com/links/file/addactivity/computer/... . SOME USEFUL SOLUTIONS * EmEditor: This was very impressive. The speed is breathtaking for what it does, and it can handle advanced functions such as column operations on the full file with ease. We chose this and users were very happy; it transformed their abilty to work with large text files. ---- These were on our shortlist to test next but we didn't get to them due to available time and EmEditor's fantastic results: * VEDIT: Designed for large files. They charge for it, IIRC, but based on its reputation it is worth the investment. * The Semware Editor (TSE): Also a great reputation * 010 Editor: http://www.sweetscape.com/010editor/ http://www.sweetscape.com/010editor/ * PilotEdit: http://www.pilotedit.com/ http://www.pilotedit.com/ ---- Also of interest: * File Query: Treats file as a database, enabling parsing, queries; very flexible and powerful, per reviews: http://www.agiledatasoftware.com/ http://www.agiledatasoftware.com/ * PDT-Windows: A database editor which reputedly has a max filesize of 18 EB (exabytes) * bvi: Binary VI [0] Some of this is copied from an earlier HN comment of mine

egh 10y ago

It's not clear exactly how this was generated, but emacs ships with a full-featured XML editor as the default XML mode (https://www.emacswiki.org/emacs/NxmlMode https://www.emacswiki.org/emacs/NxmlMode) that includes syntax and schema validation, which probably impact the XML benchmarks.

rl3 10y ago

Can anyone speak to the difference the underlying hardware makes with Atom or Code? Presumably a top-end desktop processor (~4GHz) and latest-generation NVME storage would offer really good performance, but perhaps not. If I had to guess, the average setup is probably a mobile processor paired with a traditional SSD.

majewsky 10y ago
A year ago, people made fun about how programs will get proportionally slower once all the developers have switched to SSDs. Now we're already talking about having to upgrade to NVMe disks for a decent code editing experience.
RaleyField 10y ago
Take those numbers with reserve. If anything they are 8 months old, RSS is 56 MB for hello.c on my installation of VS Code. I can run VS Code comfortably in VirtualBox on a midrange i5. Edit: Also moving around test.xml doesn't take 22 seconds, it's pretty much instantaneous, although replace is still slow.

davidw 10y ago

Time spent thinking about code and typing it in, one letter at a time: thousands and thousands of hours. Editor performance is never something I've worried about.

legulere 10y ago

VS Code seems extremely responsive to me when in use, but fairly slow to start and exit. I wonder if this makes VS Code look worse than it is in those benchmarks. What I would be interested in would be time from keystroke to screen, scrolling, etc.

Shank 10y ago

This is great and all, but I'd really prefer an updated benchmark on things I do on a minute to minute basis (e.g., time for a keypress to insert a character, time for tabs to switch, etc.) Large file benchmarks are nice, but usually I'm in a sub 1000 line file and it matters more how fast input is across the board.

jimnotgym 10y ago

I was trying a bunch of different editors last year and tried Atom out. I have used it ever since. It just seems nice to use. I am not really seeing the performance issues others are. I use it on a 1st generation i5 laptop with 4GB ram on Ubuntu, and in an Ubuntu VM on Windows 7, so I'm doing alright on low end hardware. When I have to open very large files, it is usually log files on a server and I tend to us grep and tail etc...

HugoDaniel 10y ago

been using nvi for a year now, it's a great editor, glad to see it score so well :)

bch 10y ago
You might like my occasional https://twitter.com/search?q=todayInNvi https://twitter.com/search?q=todayInNvi
- HugoDaniel 10y ago
  ah! really cool, thanks :)
- HugoDaniel 10y ago
  You have some very good tips there. Unfortunately not all of them have the #todayInNvi. Lets do a simple page with them on it ? :D
  - bch 10y ago
    You're right, they don't. I will collect them together. Glad you enjoyed them!

eddd 10y ago

As a heavy user of Atom I am surprised with the benchmarks. To me the editor is fast enough, can't provide any numbers but it is pretty responsive for daily usage (Python, C, Puppet, Elixir, Erlang)

danpalmer 10y ago
I don't use Atom at work because of speed issues - working on a codebase of ~250k lines and it takes quite a while to search/replace, and fuzzy match on file opening. I do use it on personal projects which are much smaller though.
- pawadu 10y ago
  > codebase of ~250k lines In the same file? Holy crap...

tomcam 10y ago

Performance of mcedit makes it and Midnight Commander the sleepers of the year. Didn't even know there was an mcedit, to be honest.

paule89 10y ago

I like atom just because of the easy plugin management. But it is slow as hell. Would love to use vim or emacs, but I don't want to invest too much time into learning one system. Would want to learn the better one. Too bad notepad++ only runs under wine.

mmel 10y ago

Joe seems quite fast and robust across all the tests.

nine_k 10y ago

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.

Klathmon 10y ago
It also missed the mark with many of the others on that list. The line between editor and IDE is getting more blurred every day. I use Atom. It gets opened once a day and closed at the end of the day. It could take minutes to start for all I care. The amount of time saved by having the vast set of plugins, the customization, the tools, and more greatly exceed any kind of savings I'd get from faster startup time. People tell me how I'm wrong because my editor shouldn't use so much memory, I try to tell them that I'm more than happy with the memory usage for what I get and it runs fantastically on my computer. But at the same time, I use nano on remote machines for quick edits all the time. If it were slow to start, it'd be useless. And again if I were using an older PC with 4gb of ram and a 5400RPM HDD I might feel that the performance of atom is an issue, so I'd probably use something else. I'm glad there are so many options that all focus on different workflows and features. Just because one doesn't focus on the workflow you use doesn't make it wrong or worse, just worse for you.

deleted 10y ago

[deleted]

Tomte 10y ago

I love joe. They released an up-to-date Windows binary recently, and I guess we'll get regular Windows releases now.

diroussel 10y ago

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/ https://pavelfatin.com/typing-with-pleasure/

therealdrag0 10y ago
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.

greggman 10y ago

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

agumonkey 10y ago
Emacs still has quite a lot of energy, people are working on deep levels (core, guilemacs) and the community is handling the userspace part through packages (melpa, etc). There are a few warts in a way compared to the layouting flexibilty of html/css, but beside that, the ability of emacs[-lisp] to absorb any new idea is still very high. Long time ago, when Sublime grabbed a share of the market, there was a 2 hour long video about what ST brought you. I yawned all along. The few things that weren't already in emacs appeared organically in no time; whereas 70% of features were there since the 90s. My view is biased, I'm in a lexicalist period (blame it on sml) where I want a few equations, type constraints etc and no visual flexibility (which I wanted in the past).
- oblio 10y ago
  His point wasn't that Emacs has fewer features, his point was that many of those features are half-baked compared to the implementation provided by Sublime. You give up a bit of flexibility for more stability and overall polish. That seems like a fair point.
  - 10y ago

d--b 10y ago

When I read the title, I thought this would be about the time it took to write a piece of code in each editor. Yes Visual studio has a ton of overhead, but I doubt I would write code faster using nano...

pawadu 10y ago

So basically emacs is faster than sublime on tests that are not completely made up? So why am I seeing so much praise for sublime here? Also, mg is starting to grow on me. I think it should replace nano and vi as the default unix editors.

Too 10y ago

It would be interesting to know if word wrap is turned on or off. This makes a humongous difference in some editors, especially notepad++. Turn it off and you can easily open 1GB files, turn it on and it will crash on the same file. To make the comparisons fair, the table should also include whether the editor highlights (and indexes) the file using a proper parser instead of just line-by-line regex. More realistic hardware would also be interesting. He doesn't even have SSD...

rsa4046 10y ago

Sorry, late to this party, but Gentoo/Funtoo Linux. Funtoo has git-based portage, simple to install, up and running quickly. Yes, there are still compile times to deal with, but with fast machines these are pretty minimal. I find Funtoo/Gentoo the only distribution I can maintain long term.