🚀 go-pugleaf

In article <1777@wpi.wpi.edu> jhallen@wpi.wpi.edu (Joseph H Allen) writes:
>In article <3865@mipos3.intel.com> woodstock@hobbes.intel.com (Nate Hess) writes:
>[#calls   secs real     secs cpu                      core size  program]
>   76195  624754.68re    9645.13cp        62avio         0k     gnu-emacs
>   30676  154142.85re    1043.17cp        28avio         0k     vi
>[remaining 150k deleted]

Comparing VI and Emacs in terms of CPU time used is theatrical, yes,
but somewhat like comparing apples and potatoes. It will always be
cheaper to directly control the screen than to go through a windowing
environment with smart refresh capability, but some people appreciate
having a windowing environment available (and, over current phone
lines with 1200-2400 baud, a text terminal is the only way to get
decent throughput without a LOT of expensive smarts at the terminal
end). Similarly, it will always be cheaper to dispatch directly to the
"C" routine rather than using reconfigurable keymaps and Lisp
functions -- but some people (though not as many) appreciate having
the power of a full programming language in their text editor. 

From looking at the various MicroEmacs editors, which do not have the
Lisp dispatch overhead, I have come to the conclusion that most of the
CPU time spent by Emacs is in the windowing/screen-redisplay code. I
would have to profile Emacs to see if I'm correct (and profiling GNU
Emacs is not an exercise for the faint-of-heart), but an interesting
observation is to run both MicroEmacs and GNU Emacs side-by-side on a
heavily loaded machine, and start typing keys at each one. MicroEmacs
will stutter and halt more than GNU Emacs -- unexpected, to say the
least. This implies that a) the Gosling screen redisplay algorithm is
very CPU-intensive (which Gosling himself said in his paper), and b)
GNU Emacs has a relatively efficient implementation of that
CPU-intensive routine. 
   That's not even counting the synchronization code necessary
when it is possible to have two or more windows into the same file. Will
the byte that you're currently typing in window 'A' affect what's
currently displayed in window 'B'? It'll always be more efficient to
simply say, "Nope, can't display multiple windows", and directly
control the screen, rather than have all sorts of checking code for
special cases like this.

>So assuming people do similer things with emacs and vi, emacs is about 3 times
>worse (ok, so my 4 times estimate was a bit exaggerated :-).  Actually, emacs
>may be 4 times as worse on other systems because on ours, the terminal servers
>do some of the simple editing work, but only for emacs. 

3 times worse for what? I don't use Emacs often anymore, since I do
most of my work on PCs now, but when I use Emacs, it's not likely to
be for simple text entry. I'm no VI expert, but even I find it faster
to pull up VI to enter masses of text, than to use Emacs. I often read
news using Emacs (the code is written in Emacs Lisp, meaning the CPU
is charged to Emacs), and often read/reply to mail using Emacs (again,
code in Emacs Lisp). I often use the "dired" feature to scroll back
and forth in a list of files, a feature especially helpful when I'm
trying to clean up a bunch of little netnews files that I saved to my
News directory (I can hit "o", look at it in the other window, say
"hmm, don't need that", switch window, zap it, next). I sometimes even
run a couple of shells in Emacs windows, when I want to watch two
processes going on at the same time without having to redirect the
output of one. The point of the above is that I use Emacs for a lot of
things beside text editing -- and that attributing all of Emac's CPU
usage to its "inefficiency" as a text editor is ignoring the way that
it is usually used, i.e., as a cheap windowing environment for
text-only terminals.

--
|    // Eric Lee Green              P.O. Box 92191, Lafayette, LA 70509     |
|   //    {uunet!dalsqnt,killer}!usl!elg     (318)989-9849                  |
| \X/              >> In Hell you need 4Mb to Multitask <<                  |