Path: utzoo!dptcdc!jarvis.csri.toronto.edu!mailrus!ames!killer!usl!usl-pc!jpdres10 From: jpdres10@usl-pc.usl.edu (Green Eric Lee) Newsgroups: comp.editors Subject: Re: stuff Message-ID: <267@usl-pc.usl.edu> Date: 13 Apr 89 19:09:06 GMT References: <1686@wpi.wpi.edu> <3865@mipos3.intel.com> <1777@wpi.wpi.edu> Reply-To: jpdres10@usl-pc.UUCP (Green Eric Lee) Organization: Univ. of Southwestern La., Lafayette Lines: 67 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 << |