Text Editor Performance Comparison (2016) | Hacker News Reader

Text Editor Performance Comparison (2016)

github.com

120 pointsluu68 comments

Open articleView on HN

This was submitted five months ago: https://news.ycombinator.com/item?id=13933128

Suggestion: previous submission should be at least a year old before rehashing is allowed

I don't check HN every day, so I totally missed this. I enjoyed reading it today.

The solution maybe better ways to find old content.

But having the same links resurface over and over doesn't seem optimal to me.

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

I thought of something along this lines, but your idea is better. I hope the mods are reading :)

This 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-highli...

Yeah, 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.

The speed also increased, but I use editors due to interface and usage over any speed seen.

And 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

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

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

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

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

There are ligatures in fixed-width fonts[0], like VSCode with the Fira Code font! I've been using it for a week or two now and like it so far.

[0] HN discussion: https://news.ycombinator.com/item?id=14821446

There was a whole discussion about ligatures in programming fonts here [0] a few weeks ago.

[0] https://news.ycombinator.com/item?id=14821446

Yes, specifically ligatures in fixed-width fonts like erik-g mentioned. My personal favorite is Hasklig[0], which is based on Source Code Pro.

[0]: https://github.com/i-tu/Hasklig

Okay then ... does look good ... I assume that normal ascii is used under the hood and that is what the lexical analyzer sees. I am open minded -- of course it has to work with emacs -- I am not that open minded ;)

It's just a font, the underlying text is still the same no matter what font you use to render it. In fact, you could set Fira Code (or Hasklig) as the font for your terminal and (as long as your terminal app can render ligatures) it would render in emacs or any terminal-based editor.

I can get behind it on my *nix systems, where I find it fast enough, but I find it terrible on Windows, especially when it updates and I find myself with two versions.

When 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/ [2]: http://joe-editor.sourceforge.net/

Nice to see Sublime performing so well relative to Code and Atom

Hilarious to see GNU Emacs keeping its head high in the pack of "lightweight" editors.

Not really... IMO whats far more hilarious is to see an editor written in Java handily beat the newer editors like Atom, Code, etc.

Well Atom, Code etc are written in javascript; i would wholly expect an editor written in java run laps around them.

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

Right, 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.

Think carefully about what you just posted. Java has to load the JVM. Atom and VS Code have to load Chromium.

Of course I know they load up a web browser but you would think that is something what Java people would do (in terms of over engineering and over use frameworks and fair game as I'm a Java developer).

I'm basing this on the original poster that thought it was funny that Emacs is fast/small. You don't think its ironic that a Java editor is small and fast given its history of being slow and bloated?

Surprising to see vim and nvi losing to nano and even Joe (at times)

Well, one is a well-optimized C++ implementation, the other two are Electron apps.

Not that surprising...

Why?

I ask as a recent convert to VSCode. Had spent about 18 months on ST3, and about a decade on Sublime Text 2 before that, as my daily / primary editor. Never going back.

What are some reasons you like VSCode over Sublime?

It's open source, and free, and has a superset of Sublime's abilities (for my use cases anyway).

It's been all upside, and thanks to keyboard binding import, the upgrade cost me maybe an hour total during the 1st week. IOW a ~frictionless transition.

The catalyst was annoyance w/ an ST3 plugin for Tern (tern_for_sublime). VSC ships OOB w/ things like nice autocomplete for TS and JS, and it imported all my ST3 keybindings, and I haven't found anything I want to change that's not a trivial user config option.

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

Nice that you can do so much in so many editors. Luckily, Emacs had me at hello and I will never turn back.

Approaching the subject another way, Pavel Fatin's excellent article Typing with Pleasure (https://pavelfatin.com/typing-with-pleasure/) goes really (really) deep into another way in which text editor performance can be compared

I wish IntelliJ was added to the list. It's a monster in comparison but it feels much faster than Code...

With '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'.

True 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!

I'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.

Very 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.?

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

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

For what it's worth, `sudo apt install joe` works fine on my windows machine. :)

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

So "proper" as in "the one(s) almost no one uses"?

You can install JOE on macOS through homebrew. Running "brew install joe" begins installing version 4.4

Nice.

Thanks.

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

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

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

Java virtual machines generate very efficient machine code nowadays, especially for an older codebase like jEdit's that is not particularly "object oriented".

I think it would be more fair to call it object oriented. It's just not framework oriented, and that's a good thing.

Very cool. Would be really interesting to see how neovim compares.

This is really cool. It would also be useful to provide a visualization of these numbers for easier scanning. Thanks for sharing.

why is there no good, fast, open source text editor that is user friendly like vscode but written in a low level language?

Emacs doesn't qualify? Why not?

I 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?

That would be the "user friendly" part.

To each his own, I guess. I find it user friendly enough.

This 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

Does neovim do any better than vim in any of these?

I'm wondering the same thing.

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

What is "nvi" in the tables? Neovim?

No it's the BSD clone from the nineties. Ascii only.

It's the version of vi that ships with the BSDs.

It's a version of vi distributed with many BSDs: https://en.wikipedia.org/wiki/Nvi

Reply on news.ycombinator.com