Ask HN: Best Multi-Core Text Editor?
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?
6 comments
[ 4.6 ms ] story [ 29.6 ms ] threadI 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
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.
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?
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.
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