🚀 go-pugleaf

I'm a heavy user of several variations of "micro-emacs'".  I prefer
Jove, but am using mg (MicroGnuEmacs) right now.

In article <267@usl-pc.usl.edu> jpdres10@usl-pc.UUCP (Green Eric Lee) writes:
>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]
>
>[....]
>
>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.

Since this is most of what is necessary during normal text entry and
simple editing, this is to be expected of a full-screen, interactive
text editor.  Especially one which attempts to be smart about how many
characters it sends to the terminal.

>[....] 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. 

First, GNU-Emacs doesn't seem to use the Gosling re-display algorithm,
and certainly doesn't use Gosling's code (I've never seen the skull
and crossbones in GNU-Emacs, and the style is completely different).

Second, you've got to be very careful which "micro-emacs" you are
testing.  Mg is one variation of the original Conroy MicroEmacs, and
seems to have kept most of the simple re-display code.  It's not very
smart, but probably doesn't waste much CPU either.  The Lawrence
version of MicroEmacs was also quite simplistic up to v3.7.  I've not
paid much attention to it since then, but I doubt it's much better,
since I've seen it stumble in all the places it used to.  I'd bet
people have spent more time fixing some of the bad bugs and adding the
macro language than improving the display code.

Jove is considerably smarter than either the early MicroEmacs or mg.
However it does seem to be a bit more of a CPU hog.  (I've not
actually done any comparisons, but many hours of work on both, while
sitting next to the machine (i.e. listening to the disk), it seems
Jove slows a bit more under heavier machine load.)

The only GNU-Emacs I've had experience with was 17.52 or some such
version, and though it did seem to be a bit smarter than the rest,
that version had a lot of bugs.

I haven't used Gosling Emacs since long before it was available
through UniPress, and though I've read the skull&bones code, I can't
remember enough to make a logical comparison, except to say it was a
hell of a lot smarter than MicroEmacs3.7. 

Of course all of the "micro-emacs'" versions I've seen use linked
lists to store the text.  I think this makes it much easier to write
good smart display update code.

*** opinion follows ***

If you are looking for a good "micro-emacs", I'd suggest Jove4.12 (not
easy to port to SysV, but hopefully the next version will be).  It has
most of the features I've ever used in an emacs except Lisp.
-- 
						Greg A. Woods.

woods@{{tmsoft,utgpu,gate,ontmoh}.UUCP,utorgpu.BITNET,gpu.utcs.Toronto.EDU}
+1-416-443-1734 [h],	+1-416-595-5425 [w]		Toronto, Ontario, Canada