Ask HN: Best Multi-Core Text Editor? | Hacker News Reader

Ask HN: Best Multi-Core Text Editor?

6 pointsj425 comments

So, ST3 is well written. The core C libs are fast and questionable plugin structure aside, it usually holds up well.

Atom is JS based, which is just plain slow to render.

emacs/Vim, awesome, but same issue:

When dealing with large JSON/text files none appear to have multi-threading support for complex operations (such as regex search/replace). I have an 8-core Xeon and am experiencing 2-5 minutes to render on these operations with only one core recruited.

Is there any editor that uses threads effectively to distribute operations on large files?

View on HN

This appears to be an XY problem.

Most Regex engines are built upon Nondeterministic Finite Automata with additional features. Translating NFA's to a Deterministic Finite Automata can produce an exponential number of states and hence correspondingly long run times for certain regex's.

Throwing more cores at an NFA probably doesn't help much unless you are doing things like prefetch, predictive branching, and other operations analogous to modern CPU techniques. Even if there was a Regex engine that did those things exponential time divided by number_of_cores is still exponential time. And there would still be corner cases that gained no benefit.

The practical alternatives are:

1. Tuning the regex to better performance.

2. Using another search engine such as a DFA based Regex engine like egrep, flex, or an appropriate version of awk.

3. Storing the text files in a medium designed for efficient search...i.e. a database.

4. Accept the computer science behind convenient regex implementation isn't a free lunch.

To learn more about this XY problem check out Mastering Regular Expressions from O'Reilly.

You're absolutely right and I appreciate the resource! I also think it's not the entire scope of the problem, because I'm getting the same performance reading the file and performing simple non-regex replaces on those with >10,000 lines (and syntax highlighting off).

I've checked the disk as well just to make sure it's not at fault. Sadly this machine is almost slower than my Intel Haswell MBP.

This may be an ignorant question, but as a full-stack web developer with moderate C knowledge (I've written real-time bidders and high-IO finance software but never a full GUI app), how would one go about effectively transitioning that knowledge into writing a text editor? I can look up the basic open source libs/bindings and cobble them together but I'm less knowledgeable about the proper way to go about a native UI (which it would have to be because the 'cool' technologies are simply slow).

Is the learning curve too steep for a 1yr timeline?

There are lots of one year or less effort text editors. There are a couple of four decade text editors: Emacs and vim. Really smart people have invested a lot of time in each both in extending them into green fields and working around architectural limitations. Spending a year studying their source code would be a good first research step toward writing a really good editor. That's my take on writing a text editor.

The efficiency of a text editor is an XY problem. A text editor is just a tool in a workflow. The workflow is defined by inputs and outputs. If Sublime text shells out into awk or uses MySQL as a preprocessor who cares? There's little practical point in being beholden to a particular text editor if it's in the way.

BTW, googling up "efficiency of sublime regex engine" provides some indication that Sublime chokes on modest json data. Then again, json data serializes to text, but it can easily be interpreted as data by a database engine. General tools are great, but knowing the specifics about the data allows for creating useful heuristics to guide workflows.

Do you have syntax highlighting on? I've seen huge speed-ups with large files when the editor doesn't have to try parse & highlight everything.

I agree that its annoying though. I've started writing my own text editor, and aim to solve this problem. Not quite at that point yet, however! https://github.com/gchp/iota

/shameless plug

> Atom is JS based, which is just plain slow to render.

I don't really use Atom, but they know about the find/replace issue and are working on it for the 1.0 release. That said, it's not going to be any better than other editors at that point; just comparable.

https://github.com/atom/find-and-replace/issues/145

Reply on news.ycombinator.com