sotham@blake.acs.washington.edu (Joe Sotham) (07/28/89)
Has anyone studied the relative system resource requirements for GNU emacs and other unix editors like jove, and vi. In particular I am interested in a comparison for simple text editing tasks. At the U.W. we are considering the recommendation of gnu emacs as an editor of choice for the U.W. computing community. Because individuals are allotted fixed computer resources it would be appropriate to recommend tools that use computer resources efficiently . If another editor makes more efficient use of system resources the our users would be better served by those tools. Our machines run BSD4.3. Of course there are some tasks which gnu emacs is well suited and in those cases the choice is clear. * There are no opinions here, just questions *
jym@APPLE.COM (07/29/89)
I don't think "a comparison for simple text editing tasks" is a relevant
way to judge Emacs; but if you must I would recommend that the comparison
be done with a stripped-down version of Emacs. In other words, don't count
the disk space taken up by (for example) rmail.elc as a resource for
simple editing.
I think a more relevant measure is productivity: if your computing community
can get things done more quickly with Emacs than with other editors, Emacs
might win out overall.
If you do find a comparison, I suspect you'll find that Emacs is not slow
(I've seen the code, it's quite efficient), but big (compared to simpler
editors). No surprises there . . .
<_Jym_>mellon@zayante.pa.dec.com (Ted Lemon) (07/29/89)
I don't think GNU emacs will win against vi in terms of machine usage. The reason emacs is a win is because allows for more efficient use of human time, not because it allows for more efficient use of CPU time. What you should be considering is why you're allotting computer resources the way you are. Counting time on computers discourages their use, and encourages poor programming and working practices. _MelloN_
nate@hobbes.intel.com (Nate Hess) (07/30/89)
In article <MELLON.89Jul28153756@zayante.pa.dec.com>, mellon@zayante (Ted Lemon) writes: >I don't think GNU emacs will win against vi in terms of machine usage. >The reason emacs is a win is because allows for more efficient use of >human time, not because it allows for more efficient use of CPU time. As an example of this, consider which editor would come out ahead if you were charging the user for every character that was sent to her terminal. GNU Emacs would win, since it is much more careful about screen updating than vi is. Of course, the tradeoff here is that GNU Emacs spends more CPU time than vi during a "scroll forward by a screenful" operation. >What you should be considering is why you're allotting computer >resources the way you are. Counting time on computers discourages >their use, and encourages poor programming and working practices. What's probably most important in your environment is to ensure that your limited resources are shared as fairly as possible among all the students. Ted's comment above might cause you to reexamine your methods for doing so. --woodstock -- "What I like is when you're looking and thinking and looking and thinking...and suddenly you wake up." - Hobbes woodstock@hobbes.intel.com ...!{decwrl|hplabs!oliveb}!intelca!mipos3!nate
davecb@yunexus.UUCP (David Collier-Brown) (07/31/89)
Firstly, I'd like to applaud nate@hobbes.intel.com (Nate Hess)'s comment: | What's probably most important in your environment is to ensure that | your limited resources are shared as fairly as possible among all the | students. Ted's comment above might cause you to reexamine your | methods for doing so. And secondly suggest some other ways of keeping the cost of using "expensive" user-friendly processes down. Nate continues... | As an example of this, consider which editor would come out ahead if you | were charging the user for every character that was sent to her | terminal. GNU Emacs would win, since it is much more careful about | screen updating than vi is. In Bernie Greenberg's Emacs (on Multics), one of the most expensive things was character-by-character i/o, which caused the main emacs process to start up **rather** often, burning up cpu time somewhat heavily, and getting its priority fiddled with as a result... The solution was to note that the most common single operation was (self-insert), and convince the front-end processor to wake up emacs only when someone typed a character which wasn't obviously going to be self-inserted. When emacs did wake up, it y got handed a buffer full of characters, the last of which was usually a carriage-return! In order that one not have to remember what one typed, the front end was told to echo the non-special, self-insert characters. Emacs itself got told about switching the FEP's echoing on and off, and about efficiently self-inserting whole strings of characters. The whole thing was an absolute win over communications lines, and gave better response in Waterloo, Ontario talking to emacs in Minneapolis than when talking to a non-emacs editor on a machine in the next room. It wasn't bad when the machine was nearby, either. The scheme is called "negotiated echo", and can be usefully simulated with a pipe and a tiny input process. I used it in front of a **VERY** i/o-inefficient screen-display program and got substantial reductions in in both i/o and cpu usage. I doubt if something that simple would help emacs (which is far better quality than the code I was playing with), but the basic idea is applicable. --dave (if anyone wants details, mail me) c-b -- David Collier-Brown, | davecb@yunexus, ...!yunexus!davecb or 72 Abitibi Ave., | {toronto area...}lethe!dave Willowdale, Ontario, | Joyce C-B: CANADA. 223-8968 | He's so smart he's dumb.