Path: utzoo!mnetor!tmsoft!woods From: woods@tmsoft.uucp (Greg Woods) Newsgroups: comp.editors Subject: Re: stuff Summary: timing various emacs variants Keywords: emacs cpu editors Message-ID: <1989Apr17.230643.21642@tmsoft.uucp> Date: 17 Apr 89 23:06:43 GMT References: <1686@wpi.wpi.edu> <3865@mipos3.intel.com> <1777@wpi.wpi.edu> <267@usl-pc.usl.edu> Reply-To: woods@tmsoft.UUCP (Greg Woods) Organization: G.A.W. Consulting Lines: 74 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