Path: utzoo!yunexus!davecb From: davecb@yunexus.UUCP (David Collier-Brown) Newsgroups: gnu.emacs Subject: Re: Relative cost of GNU Emacs vs Vi. Message-ID: <2987@yunexus.UUCP> Date: 30 Jul 89 20:35:30 GMT Article-I.D.: yunexus.2987 References: <2992@blake.acs.washington.edu> <585@mipos3.intel.com> Organization: York U. Computing Services Lines: 51 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.