Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!inuxc!pur-ee!j.cc.purdue.edu!i.cc.purdue.edu!arthur.cs.purdue.edu!narten
From: narten@arthur.cs.purdue.edu.UUCP
Newsgroups: comp.emacs
Subject: Re: GNU Emacs performance
Message-ID: <1470@arthur.cs.purdue.edu>
Date: Thu, 28-May-87 21:28:46 EDT
Article-I.D.: arthur.1470
Posted: Thu May 28 21:28:46 1987
Date-Received: Thu, 4-Jun-87 01:44:18 EDT
Sender: news@arthur.cs.purdue.edu
Organization: Department of Computer Science, Purdue University
Lines: 32

In article  <3800@oddjob.UChicago.EDU> matt@oddjob.UChicago.EDU (Ke Kupua) writes:
>Thus, either people leave suspended GNU emacs
>sessions around a lot longer, or it uses propotionately
>less cpu time than the other leading brands.
>

I would bet money that people do leave emacs suspended a lot more than
vi.  The people that I know that use emacs, log in, start emacs, and
go about their business. Most never get out of emacs once its started,
and many don't log out either. For vi, a more typical scenario would
be to start and exit for each file.

Hence, I doubt the cpu consumption to elapsed time ratio has any
meaning.

There is no way that emacs (any flavor) can run faster than vi. [Spare
the flames about the highly optimized assembler coded version :-)]
Think about it. In emacs, each keystroke is bound to an interpreted
lisp function. In vi, its bound to compiled code. If your emacs runs
as fast as vi, you aren't doing anything interesting (read: you aren't
using any lisp functions), and you might as well be using vi.

If you are worried that emacs is too much of a resource drain on your
system, emacs is not your problem. Your system is. That same argument
encourages using ed instead of vi. Yes, emacs uses more resources than
vi. But it does much more. People that use emacs use it because they
like its power (windows and extensibility). Ultimately, it makes them
more productive. If I was debating whether my site should install
emacs, that argument says it all.
-- 
Thomas Narten
narten@cs.purdue.EDU or {ihnp4, allegra}!purdue!narten