6 ms·
Text Editor Performance Comparison (2016)
- laylomo2 9y agoThis is really cool. It would also be useful to provide a visualization of these numbers for easier scanning. Thanks for sharing.
- deleted 9y ago[deleted]
- nooreen 9y agoNice that you can do so much in so many editors. Luckily, Emacs had me at hello and I will never turn back.
- deleted 9y ago[deleted]
- michaelmior 9y agoVery cool. Would be really interesting to see how neovim compares.
- nkkollaw 9y agoVery cool. I thought Nano would perform much better..? A problem with some fast editors might be ease of use. For instance, I would have loved to try out JOE editor, but I couldn't find builds, the code is hosted on Sourceforge, etc. etc. I think a huge feature for an editor is usability: is there a website where I can download a build for my OS? Does it update by itself? Is it easy to configure, install plugins, etc.?
- zeptomu 9y agoAssuming you are on a proper OS, it comes with your distribution, e.g. via Ubuntu it's just $ apt install joe And it's ready (obviously you might want to configure it differently than the default).
- mikejmoffitt 9y agoI agree with you about a package manager being a good OS feature, but this is unnecessary snark when the two most popular operating systems don't come with a package manager (of this sort, at least).
- a_t48 9y agoFor what it's worth, `sudo apt install joe` works fine on my windows machine. :)
- mikejmoffitt 9y agoJoke aside, that didn't install a Windows program, and I'm willing to bet the WSL wasn't installed by default either, and I'll also bet that didn't work in a Windows command prompt.
- EpicEng 9y agoSo "proper" as in "the one(s) almost no one uses"?
- pselbert 9y agoYou can install JOE on macOS through homebrew. Running "brew install joe" begins installing version 4.4
- nkkollaw 9y agoNice. Thanks.
- doktrin 9y agoNice to see Sublime performing so well relative to Code and Atom
- ajross 9y agoHilarious to see GNU Emacs keeping its head high in the pack of "lightweight" editors.
- agentgt 9y agoNot really... IMO whats far more hilarious is to see an editor written in Java handily beat the newer editors like Atom, Code, etc.
- throwaway91111 9y agoWell Atom, Code etc are written in javascript; i would wholly expect an editor written in java run laps around them.
- agentgt 9y agoWell that is sort of like saying Emacs is written in Elisp. Its true a good portion of the editors are written in their own scripting language (js for atom, and elisp for emacs, and beanshell for jedit) but I believe the critical components that these tests test for are probably not.
- throwaway91111 9y agoRight, i guess that was my point as well. The java factor probably doesn't play into the core speed. I would imagine the rendering is what screws the performance for the js based editors.
- btym 9y agoThink carefully about what you just posted. Java has to load the JVM. Atom and VS Code have to load Chromium.
- mzzter 9y agoI really wanted to give Atom a chance since it gets stuff like ligatures right, but I find its slow startup speed to be a no-go. I simply find in Sublime a much stabler experience and faster startup time, which makes it feel more productive.
- cshenton 9y agoSo did I. And every time I downloaded it again, I'd open a medium sized file, scroll down, the scroll lags, and I delete it again.
- mclehman 9y agoI was very pro-Atom for a while. I've since packed up and moved to Vim and then on to Emacs with evil-mode. I never had any performance complaints while I was actually using Atom, but a while back I made a mistake when generating a text file that turned out to be ~1.5GB. Luckily, it was just one mistake in the footer, so I could take care of it without regenerating the entire thing. Without even thinking about it, I opened it up with Emacs, went to the bottom, made my changes, and got back out. About a minute later, I saw how large of a file it was and was suddenly even more impressed with Emacs than I had been. Just for fun, I then tried to edit it with Atom. Nope.
- waynecochran 9y agoligatures in source code? It seems as soon as I use a non-fixed width font, then indenting and other code formatting becomes tricky. Bjarne Stroustrup uses a proportional spaced font in his C++ book and I hate it.
- pselbert 9y agoWhen I read the headline I thought it would be a link to Dan Luu's recent post [1]. Not too surprising that it was actually submitted by him! The most amazing part of this is the JOE editor. Performance and memory aside, I'm astounded it has been maintained by the same person since 1988! [2] [1]: https://danluu.com/term-latency/ https://danluu.com/term-latency/ [2]: http://joe-editor.sourceforge.net/ http://joe-editor.sourceforge.net/
- lihaoyi 9y agoApproaching the subject another way, Pavel Fatin's excellent article Typing with Pleasure (https://pavelfatin.com/typing-with-pleasure/ https://pavelfatin.com/typing-with-pleasure/) goes really (really) deep into another way in which text editor performance can be compared
- hammerandtongs 9y agoThis is lacking input latency unfortunately ie how long it takes for a typed character to appear. That unsurprisingly quite critical and surprisingly variable - https://pavelfatin.com/typing-with-pleasure/#input-latency https://pavelfatin.com/typing-with-pleasure/#input-latency
- loeg 9y agoDoes neovim do any better than vim in any of these?
- fishywang 9y agoI'm wondering the same thing.
- keyle 9y agoI wish IntelliJ was added to the list. It's a monster in comparison but it feels much faster than Code...
- crispinb 9y agoWith 'zero-latency typing' enabled (which it is by default on current versions), IntelliJ rates well on typing lag comparisons which are probably the most consequent metric for 'feel'.
- keyle 9y agoTrue I can't stand typing in a "text editor" only to see it lagging behind. That wasn't a thing back in DOS and that shouldn't be a thing today!
- badpenny 9y agoI've always had problems with IntelliJ IDEA feeling extremely slow and have never been able to figure out why. The mouse cursor even skips when it's doing anything intensive. This is on a machine with 4 cores @ 3.2GHz and 16GB of RAM. VSCode seems much faster.
- whatever_dude 9y agoThis is from September 2016. I'm sure many editors there have changed since then. This is true of Visual Studio Code, at least - the tests uses 1.4, way behind the current 1.14. I know the team has been spending some time doing performance improvements (e.g. 1.9 had some big improvements in highlight performance[1]) and I wonder how it compares. 1: https://code.visualstudio.com/blogs/2017/02/08/syntax-highlighting-optimizations https://code.visualstudio.com/blogs/2017/02/08/syntax-highli...
- theaustinseven 9y agoYeah, for reference, VS Code had just a couple of months prior added editor tabs. The VS Code today is vastly different from the one a year ago.
- baldfat 9y agoThe speed also increased, but I use editors due to interface and usage over any speed seen.
- Laurel_ 9y agolm måκlng оvêя $7κ å mоnтн шояκlng påят тlmê. l κêpт нêåяlng отнêя pêоplê тêll mê нош mucн mоnêy тнêy cån måκê оnllnê Sо l DêclDêD то lооκ lnто lт. шêll, lт шåS åll тяuê ånD нåS тотålly cнångêD my llfê. тнlS lS шнåт l Dо, ====http://www.financemedianews.com/?682 http://www.financemedianews.com/?682
- ianstormtaylor 9y agoAnd it looks like just today Atom has another release (1.19) that supposedly helps performance for large documents: http://blog.atom.io/2017/08/08/atom-1-19.html http://blog.atom.io/2017/08/08/atom-1-19.html
- agentgt 9y agoOh man I forgot about JED! It was my first editor. At the time Emacs was often too slow on my computer (circa 1995 maybe even as early as 93). That editor was awesome and it had a cool library I think called Slang which had its own sort of ncurses implementation and scripting language (probably wrong on the details). The author also implemented an awesome news reader back you know when people used news readers.
- 6502nerdface 9y ago> At the time Emacs was often too slow on my computer (circa 1995 maybe even as early as 93). Recalls to mind that old joke, "Eight Megs And Constantly Swapping."
- agentgt 9y agoI'm actually sort of impressed how well JEdit performed. Other than micro its one of the only not written in a C/C++ language (the critical components... I realize emacs, code, atom, sublime all have their extension languages).
- slavapestov 9y agoJava virtual machines generate very efficient machine code nowadays, especially for an older codebase like jEdit's that is not particularly "object oriented".
- lokedhs 9y agoI think it would be more fair to call it object oriented. It's just not framework oriented, and that's a good thing.
- bronz 9y agowhy is there no good, fast, open source text editor that is user friendly like vscode but written in a low level language?
- sidlls 9y agoEmacs doesn't qualify? Why not?
- Spivak 9y agoI think it should count. Emacs might come from a different time but it's plenty user friendly for a text editor, it even has graphical menus and a package manager. What more do you want?
- ledgerdev 9y agoThat would be the "user friendly" part.
- sidlls 9y agoTo each his own, I guess. I find it user friendly enough.
- tambourine_man 9y agoThis was submitted five months ago: https://news.ycombinator.com/item?id=13933128 https://news.ycombinator.com/item?id=13933128 Suggestion: previous submission should be at least a year old before rehashing is allowed
- Uehreka 9y agoI don't check HN every day, so I totally missed this. I enjoyed reading it today.
- tambourine_man 9y agoThe solution maybe better ways to find old content. But having the same links resurface over and over doesn't seem optimal to me.
- infogulch 9y agoThere is a "past" link at under the article link that opens up agnolia search. I'm gonna throw out the idea that it should show the number of exact url results right there without having to click it.
- tambourine_man 9y agoI thought of something along this lines, but your idea is better. I hope the mods are reading :)
- to3m 9y agoI was moved to try Emacs with my own test file and (somewhat to my surprise - it's normally pretty crap with long lines) it had no problem loading a 3GByte file consisting of 3,000,000 1K lines. For short lines it's generally fine. I've never had a problem working with multi-GByte log files with 100-chars per line or so. (Even if it's OK for text, you are probably best off avoiding very large source files - some of the major modes seem to be written assuming <100K files and/or short lines. Python mode in particular seems to bog down very easily. C mode is fine for editing, but large-scale reindents can get pretty slow. And so on.)
- hossbeast 9y agoWhat is "nvi" in the tables? Neovim?
- billsnow 9y agoNo it's the BSD clone from the nineties. Ascii only.
- steinuil 9y agoIt's the version of vi that ships with the BSDs.
- cristoperb 9y agoIt's a version of vi distributed with many BSDs: https://en.wikipedia.org/wiki/Nvi https://en.wikipedia.org/wiki/Nvi
- ledgerdev 9y agoI guess the focus on large files has it's certainly useful in certain cases like viewing log files, data dumps, etc... but for the most part I find myself opening many many small files with less than a couple hundred lines each. We need tools that focus on application development needs, not text editing.