[Beowulf] [OT] EMACS vs VI

[Andrew Piskorski]

On Thu, Feb 17, 2011 at 10:44:14PM +0700, C. Bergstr?m wrote:

> fwiw some people still *really* care about emacs performance even on 
> modern hw.  We (PathScale) have a few vocal users and plan to spin some 
> cycles to speed it up a bit.

[Well as long as we're almost totally off topic...]

As a constant (X and Gnu) Emacs user for the last 11 years, I can say
that only rarely has its serial speed ever been a problem, and then
usually solved by Don't Do That.  E.g., turn off font-lock-mode in any
shell buffers that might receive many thousands of lines of output;
don't try to read massive mail folders in VM, use mutt under screen
instead.

Emacs's glaring weakness is its pervasive single-threadedness.  Its
whole UI will just lock up completely in many cases, with the cpu
pegged at 100%, when it can't keep up with output from some child
process.  E.g., R spitting out some sort of absurdly large backtrace,
which ess-mode tries to parse or markup in some fashion.  In those
cases, the only solution is generally to switch to a different shell
and kill the child process; then Emacs will recover.

Emacs needs more concurrency.  Although ironically, continuing to run
on just 1 cpu core would be adequate; it's its lack of UI
responsiveness under stress that's just stupid.  Firefox seems to have
been gradually getting better at that, although version 3.6.13 is
still far from perfect.  AFAICT Emacs hasn't made any similar
progress, but I admit I haven't looked.  It's good enough in other
ways that I merely put up with its few grating flaws.

Although now that I think of it, since the slow output-parsing stuff
in Emacs is probably implemented by running one or more regular
expression matches on every single line, it might be helpful to
retrofit an efficient linear time regexp engine like Russell Cox's
RE2:

   http://swtch.com/~rsc/regexp/regexp3.html
   "Regular Expression Matching in the Wild", by Russ Cox, March 2010
   http://code.google.com/p/re2/
   http://swtch.com/~rsc/regexp/

   http://sljit.sourceforge.net/regex_perf.html
   Performance comparison of regular expression engines

-- 
Andrew Piskorski <atp at piskorski.com>
http://www.piskorski.com/