Suggestion: previous submission should be at least a year old before rehashing is allowed
But having the same links resurface over and over doesn't seem optimal to me.
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'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) and I wonder how it compares.
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.
 HN discussion: https://news.ycombinator.com/item?id=14821446
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! 
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?
Not that surprising...
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.
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.
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.)
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.?
$ apt install joe
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.
Recalls to mind that old joke, "Eight Megs And Constantly Swapping."
That unsurprisingly quite critical and surprisingly variable -
We need tools that focus on application development needs, not text editing.