[comp.emacs] GNU Emacs performance

mkhaw@vaxc.ARPA (Michael Khaw) (05/19/87)

Is GNU Emacs a CPU hog (at least relative to vi, for example)?  Whenever I
do a "ps", the emacs processes seem to generally have consumed more CPU time
than most other user processes.  Is that because emacs users tend to do
nearly everything from within emacs (shell buffers, dired, etc), or is it
GNU Emacs itself?

Mike Khaw
-- 
internet:  mkhaw@teknowledge-vaxc.arpa
usenet:	   {hplabs|sun|ucbvax|decwrl|sri-unix}!mkhaw%teknowledge-vaxc.arpa
USnail:	   Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303

narten@percival.cs.purdue.edu (Thomas Narten) (05/21/87)

>Is GNU Emacs a CPU hog (at least relative to vi, for example)?

Of course it is! But then, isn't vi a cpu hog relative to ed?

-- 
Thomas Narten
narten@cs.purdue.EDU or {ihnp4, allegra}!purdue!narten

todd@uhccux.UUCP (05/26/87)

In article <1439@arthur.cs.purdue.edu> narten@percival.cs.purdue.edu (Thomas Narten) writes:
>>Is GNU Emacs a CPU hog (at least relative to vi, for example)?
>Of course it is! But then, isn't vi a cpu hog relative to ed?

Well, I don't think that answers the original question.  I'd also like to
know if anyone has seriously looked at the resources used by GNU EMACS.
I'm just about to turn on accounting on a VAX 8650 and would like to be able
to answer users' questions about EMACS' usage of CPU resources.

My offhand response is that it seems to be a hog of program.  It seems to
been in run state more often than other programs.  But that seems reasonable
since, as the the person who asked the question said, EMACS users tend
to do "everything" from within EMACS.  Still, I'd like to know if someone
has done some serious looking into how much EMACS uses on a "typical
system" (whatever that is).  With all the screen updating, use of
psuedo-tty, etc., it seems like EMACS would be a real resource hog...todd

-- 
Todd Ogasawara, U. of Hawaii Computing Center
UUCP:		{ihnp4,seismo,ucbvax,dcdwest}!sdcsvax!nosc!uhccux!todd
ARPA:		uhccux!todd@nosc.MIL
INTERNET:	todd@uhccux.UHCC.HAWAII.EDU

jpn@teddy.UUCP (John P. Nelson) (05/26/87)

>>Is GNU Emacs a CPU hog (at least relative to vi, for example)?
>Of course it is! But then, isn't vi a cpu hog relative to ed?

Well, I suspect that part of why GNU runs so slowly is:

  1.  Memory Usage.  GNU may do lots of paging on machines with small real
      real memory sizes.  First, the executable is large.  Also, EVERYTHING
      is kept in memory.  If you are editing a 3 Meg file, you need all 3 Meg
      IN (virtual) MEMORY at once.  Vi uses a temp file, and only keeps the
      active part of the file in memory.

  2.  Lisp code.  Significant parts of the GNU functionality is written
      in LISP.  Unfortunately, the LISP is interpreted, not compiled.
      For instance, several of our users here were using the C mode of
      GNU, and I noticed that those copies of emacs were using LOTS more
      cpu than users using the fundmental mode.  Other frequently used
      functions are written in LISP as well.

matt@oddjob.UChicago.EDU (Ke Kupua) (05/26/87)

One measure of cpu consumption is the ratio of elapsed time
to cpu (system+user) time.  The exact relevance is debatable.
For the past 4 weeks the ratio of elapsed to cpu time for
GNU emacs on this system has been 47.2.  For Unipress emacs
(#264 - a very old version), the ratio has been 21.5 and
for vi, 35.9.  Thus, either people leave suspended GNU emacs
sessions around a lot longer, or it uses propotionately
less cpu time than the other leading brands.

		Matt Crawford

jr@ALEXANDER.BBN.COM (John Robinson) (05/27/87)

>>   2.  Lisp code.  Significant parts of the GNU functionality is written
>>       in LISP.  Unfortunately, the LISP is interpreted, not compiled.
>>       For instance, several of our users here were using the C mode of
>>       GNU, and I noticed that those copies of emacs were using LOTS more
>>       cpu than users using the fundmental mode.  Other frequently used
>>       functions are written in LISP as well.

Well, lisp code can be byte-compiled; this makes it faster and
somewhat smaller.  Better would be to include any commonly-used elisp
packages in the shared image via the site-init.el file; then all the C
users share one copy of the (complied) elisp, and the swapping load
should drop.  Remember to up the PURESIZE parameter when making emacs
if you add a significant amount to the load image.

We have found this to be a big win.  Even on a worksatation, using
purified code helps since the pages don't need to be swapped out (they
are re-loaded from the execute image, not the swap device, and never
get written).

/jr

narten@arthur.cs.purdue.edu.UUCP (05/29/87)

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

pd@sics.UUCP (Per Danielsson) (05/29/87)

In article <4041@teddy.UUCP> jpn@teddy.UUCP (John P. Nelson) writes:
>Well, I suspect that part of why GNU runs so slowly is:
>
>  1.  Memory Usage.  GNU may do lots of paging on machines with small real
>      real memory sizes.  First, the executable is large.  Also, EVERYTHING
>      is kept in memory.  If you are editing a 3 Meg file, you need all 3 Meg
>      IN (virtual) MEMORY at once.  Vi uses a temp file, and only keeps the
>      active part of the file in memory.

This is of course not a fault of GNU Emacs. A well designed virtual
memory system should be as efficient in core vs. disk space usage as
any temp file scheme. If you have to resort to writing the code for
swapping to disk yourself the virtual memory system is probably poorly
written. (Followups to this should go to some other newsgroup than
comp.emacs).

-- 
Per Danielsson          UUCP: {mcvax,decvax,seismo}!enea!sics!pd
Swedish Institute of Computer Science
PO Box 1263, S-163 13 SPANGA, SWEDEN
"No wife, no horse, no moustache."

rbj@ICST-CMR.ARPA (Root Boy Jim) (06/09/87)

? >>Is GNU Emacs a CPU hog (at least relative to vi, for example)?
? >Of course it is! But then, isn't vi a cpu hog relative to ed?
? 
? Well, I suspect that part of why GNU runs so slowly is:
? 
?   1.  Memory Usage.  GNU may do lots of paging on machines with small real
?       real memory sizes.  First, the executable is large.  Also, EVERYTHING
?       is kept in memory.  If you are editing a 3 Meg file, you need all 3 Meg
?       IN (virtual) MEMORY at once.  Vi uses a temp file, and only keeps the
?       active part of the file in memory.

Paging or swapping is faster than going thru the file system. The only
thing that would make emacs slower is if the entire file was read in
before any of it was used.
 
?   2.  Lisp code.  Significant parts of the GNU functionality is written
?       in LISP.  Unfortunately, the LISP is interpreted, not compiled.
?       For instance, several of our users here were using the C mode of
?       GNU, and I noticed that those copies of emacs were using LOTS more
?       cpu than users using the fundmental mode.  Other frequently used
?       functions are written in LISP as well.

Semi-true. The `lisp' is `compiled' but not to machine code. So while
the `compiled lisp' *is* interpreted, all the parentheses and symbol
scanning/lookups have been done. It is much like emulating another 
machines assembly language by `executing' the `object code'.

Since editors are mostly I/O bound, this seldom hurts.

	(Root Boy) Jim Cottrell	<rbj@icst-cmr.arpa>
	National Bureau of Standards
	Flamer's Hotline: (301) 975-5688
	..  are the STEWED PRUNES still in the HAIR DRYER?

neves@ai.WISC.EDU (David M. Neves) (06/09/87)

> 
>?   2.  Lisp code.  Significant parts of the GNU functionality is written
>?       in LISP.  Unfortunately, the LISP is interpreted, not compiled.
>Semi-true. The `lisp' is `compiled' but not to machine code. So while
>the `compiled lisp' *is* interpreted, all the parentheses and symbol
>scanning/lookups have been done. It is much like emulating another 
>machines assembly language by `executing' the `object code'.
I believe a more accurate analogy would be to Pascal's P-code.  GNU
emacs compiles down to a pseudo code of an abstract stack machine
which is then interpreted.  

"all the parentheses and symbol ..."  This scanning occurs during
reading of Lisp s-expressions, not during execution or compilation.
When an s-expression is read in from a file it is turned into a binary
tree structure with leaf nodes as pointers to atoms (not strings!).
Parentheses do not exist in this internal representation.
David Neves, Computer Sciences Department, University of Wisconsin-Madison
Usenet:  {allegra,heurikon,ihnp4,seismo}!uwvax!neves
Arpanet: neves@cs.wisc.edu

john@xanth.UUCP (John Owens) (06/10/87)

In article <8706091546.AA01577@icst-cmr.arpa.ARPA>, rbj@ICST-CMR.ARPA (Root Boy Jim) writes:
> ? >>Is GNU Emacs a CPU hog (at least relative to vi, for example)?
> Paging or swapping is faster than going thru the file system. The only
> thing that would make emacs slower is if the entire file was read in
> before any of it was used.

Yes, but VI also reads in the entire file, as do all other UNIX
editors that I've used.  I would be interested to know of editors that
don't do this - there are times that I'd love to go through a huge
(megabytes) output file with an editor.

So: What editors that run on versions of UNIX only read in the file
when necessary?  How do they get around problems with the file
changing while it is being edited and the like?

-- 
John Owens		Old Dominion University - Norfolk, Virginia, USA
john@ODU.EDU		old arpa: john%odu.edu@RELAY.CS.NET
+1 804 440 4529		old uucp: {seismo,harvard,sun,hoptoad}!xanth!john

john@xanth.UUCP (06/11/87)

[Yes, I know, a followup to my own article....]

I also wanted to mention what VMS EDT does with regard to reading in
files.  It starts up only reading in the first few blocks of the file,
and reads in the rest as you move through the file.  Unfortunately, it
still reads everything up to your current position, so if you edit a
huge file, it starts up instantly, but skipping to the bottom of the
file takes a lot of time (as it obnoxiously blinks "Working...." on
and off at the bottom of the screen (and not with a blink attribute
either)).

I'm hoping someone out there knows of an editor that reads in chunks
of the file as it needs them, and yet deals somehow with the
possibility of getting an inconsistent file.  Does anyone have any
ideas on that?  If there is a "good" way to handle it, perhaps we can
add that to gnu-emacs (controlled by a variable, of course).

-- 
John Owens		Old Dominion University - Norfolk, Virginia, USA
john@ODU.EDU		old arpa: john%odu.edu@RELAY.CS.NET
+1 804 440 4529		old uucp: {seismo,harvard,sun,hoptoad}!xanth!john

jimp@cognos.uucp (Jim Patterson) (06/19/87)

In article <1206@xanth.UUCP> john@xanth.UUCP writes:

>I also wanted to mention what VMS EDT does with regard to reading in
>files.  It starts up only reading in the first few blocks of the file,
>and reads in the rest as you move through the file.  ...
>I'm hoping someone out there knows of an editor that reads in chunks
>of the file as it needs them, and yet deals somehow with the
>possibility of getting an inconsistent file.  Does anyone have any
>ideas on that?

You could do this with a unix-type file, i.e. one with newlines to
separate logical lines.  You can just jump to a block near the end of
the file and scan forward to a newline.  You wouldn't be able to tell
the line-number that you are currently editing, though.

VMS has a filetype that is similar to this called stream_lf.  (It's
fairly recent, having been introduced in VMS 4.0 or maybe even later).
However, most text files under VMS are stored as variable-length RMS
files which means that there is a one-word count of characters
preceeding each record which tells how big it is.  Usually there is no
explicit newline. With this structure there is no reliable way that
you can jump into the middle of the file and re-synchronize yourself
to a record boundary.  Any algorithms to do so have to make
assumptions about what characters are valid or aren't valid in a file.
If you assume that the file contains no actual NULs and that
line-lengths are not in excess of 255 characters then you can locate
the record breaks by locating NUL characters.  (The preceding
character will then be the length of the next line).  However, to do
even this requires that you bypass RMS (or use RMS block I/O), since 
RMS will return records from a variable-length file only sequentially.
(There may be a way to fool it once you've located the record you want
to position to, but I'm not enough of an RMS wizard to comment on how).


-- 

Jim Patterson          decvax!utzoo!dciem!nrcaer!cognos!jimp
Cognos Incorporated