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 94303narten@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!nartentodd@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!johnjimp@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