
Ask HN: Best Multi-Core Text Editor? - j42
So, ST3 is well written.  The core C libs are fast and questionable plugin structure aside, it usually holds up well.<p>Atom is JS based, which is just plain slow to render.<p>emacs&#x2F;Vim, awesome, but same issue:<p>When dealing with large JSON&#x2F;text files none appear to have multi-threading support for complex operations (such as regex search&#x2F;replace).  I have an 8-core Xeon and am experiencing 2-5 minutes to render on these operations with only one core recruited.<p>Is there any editor that uses threads effectively to distribute operations on large files?
======
brudgers
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.

~~~
j42
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?

~~~
brudgers
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.

------
gchp
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](https://github.com/gchp/iota)

/shameless plug

------
jdc0589
> 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](https://github.com/atom/find-and-replace/issues/145)

