jhallen@wpi.wpi.edu (Joseph H Allen) (04/04/89)
> Why invent another language when we have LISP? YUK! YUK! AWK! GREP! YACCC! - sorry, but lisp is definately not on my top-ten list of "I don't even have to think about it" languages. BASIC or a structured language with no punctuation would be much better than lisp as a editor/macro language. It's my opinion that the only reason we find lisp as a macro language in so many environments is that it only takes about 1 day of programming to implement a simple (gnu-emacs-mlisp like) lisp interpreter. > EMACS is so slow! There is no excuse for an editor to be slow- even on heavily loaded machines. If the editor is properly designed, then the number of operations needed to do any simple editing function like positioning the cursor or inserting typed-in text should be negligable- even if you have to interpret lisp. GNU-EMACS is slow because when you do cursor positioning (that is, when you do anything), it has to _search_for_ '\n's. It would probably be much faster if it used the 'doubly linked list of lines' approach instead of the 'extracted buffer approach' of accessing the buffer in memory. For example, vi is 4 times less CPU hungry than emacs is. No way is all of that due to EMACS being lispified. Two other speed problems bother me. First, there's the "network-slowness" problem. I'm writting this message on an ENCOREmultimax. This is an extrememly powerfull multiprocessing unix machine on which even GNU-EMACS flies. The ENCORE has three cables comming out of it: the power cord, the console terminal line and an ethernet cable. Even though the ENCORE is fast, terminal I/O can be slow because at any given time, there's 100 people on the network. To make matters worse, the full network protocol overhead is invoked for each characer you type. With this overhead for each character, the line speed ends up being equivelent to about 300 baud. To try to get around this problem, ENCORE decided to build a simple editor into their 'annex' ethernet terminal server. The terminal server does as much editing as it can without communicating with the host. As soon as you do an edit function which requires information which the terminal server doesn't have, the terminal server dumps all the characters you've typed so far to the host for a screen update. This leads us to the next speed problem: stupidness when dealing with slow terminals- or terminals on 1200 baud phone lines. Networks and, to a lesser degree, unix really like to bunch data into large blocks to increase throughput. This is a terrible thing for slow terminals because it means large outputs can't be 'interrupted'. If you accidentally hit the page-down key, then you have to wait 1/2 a minute for the screen to be restored. And God help you if you have a terminal which can't insert characters... - - - - - So, my wish-list for an editor is: * every long operation must be abortable * every lengthy screen update must be interruptable * it must be easy to program * the following commands HAVE to be single key or control keys with none of that vi mode switching junk: Cursor up Cursor down Cursor right Cursor left Page up Page down Word left Word right Beg. of line End of line Delete char. Delete word Delete line Delete to eol Search/Replace next thing Insert a previously cut/copied block Undo Enter ctrl char * the following commands should take no more than 2 key-presses to get: Top of file Bot of file Search Insert/overwrite Goto line No. Shell escape Exit and save Exit and abort Insert file Cut/Copy block Save block to file * DEL and ^H must both backspace * And, most importantly and with religeous intensity, when moving between lines, the cursor MUST NOT EVER change column position. If the cursor gets placed after the end of a line or if it gets placed in the middle of a tab field, then, on the next command which requires the cursor to be in a valid position, the cursor should jump to the beginning of the next line, end of current line or beginning or end of the tab field, depending on the command.
mikeg%watson.c3@lanl.gov (M.P.Gerlek) (04/04/89)
From article <1686@wpi.wpi.edu>, by jhallen@wpi.wpi.edu (Joseph H Allen): > So, my wish-list for an editor is: > > * every lengthy screen update must be interruptable There must be _NO_ "lengthy screen updates". > * the following commands HAVE to be single key or control keys with none of > that vi mode switching junk: > [...] > * the following commands should take no more than 2 key-presses to get: > [...] > * DEL and ^H must both backspace Any editor worth its name must have the ability to bind keys in a permanent, user-happy manner. EMACS and EVE both have all of this... User preferences must NOT be set by The Powers That BE. > * And, most importantly and with religeous intensity, when moving between > lines, the cursor MUST NOT EVER change column position... Amen! (with equally religious fervor) ` M.P.Gerlek (mikeg@watson.c3.lanl.gov) "To tweak, ' ` Los Alamos Nat'l Lab / Merrimack College Or not to tweak? ' ` That is the ' ` Disclaimer: I'm only an undergrad, they don't Question." ' ` tell me anything worth disclaiming. '
sommar@enea.se (Erland Sommarskog) (04/04/89)
Joseph H Allen (jhallen@wpi.wpi.edu) writes: > * And, most importantly and with religeous intensity, when moving between > lines, the cursor MUST NOT EVER change column position. If the cursor gets > placed after the end of a line or if it gets placed in the middle of a tab > field, then, on the next command which requires the cursor to be in a valid > position, the cursor should jump to the beginning of the next line, end of > current line or beginning or end of the tab field, depending on the command. Another "Hear, hear, I couldn't agree more" from me. It always drives me crazy when the cursor suddenly sticks away from the given path to the beginning of line because there happened to be an empty line. Before TPU came along, I used EDT on VMS, and I never learn to live with it. I have been thinking of learning my profile to do it, but hesitated, since it's so god damn slow already. GNU-Emacs has a mood for it, and, yes, TPU has too, although TPU does in a little strange way. Anyway, a good editor should provide the other way too, for those who prefer. Yes, TPU, does that too. -- Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se I used to say "It could have been worse, it could have been Pepsi", then I drank a Diet Coke...
chris@mimsy.UUCP (Chris Torek) (04/05/89)
>In article <1686@wpi.wpi.edu> jhallen@wpi.wpi.edu (Joseph H Allen) notes >> * every lengthy screen update must be interruptable In article <11473@lanl.gov> mikeg%watson.c3@lanl.gov (M.P.Gerlek) writes: >There must be _NO_ "lengthy screen updates". At 300 baud, *every* screen update is lengthy. You have made an impossible demand. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
jhallen@wpi.wpi.edu (Joseph H Allen) (04/05/89)
In article <11473@lanl.gov> mikeg%watson.c3@lanl.gov (M.P.Gerlek) writes: >From article <1686@wpi.wpi.edu>, by jhallen@wpi.wpi.edu (Joseph H Allen): >> So, my wish-list for an editor is: >> >> * every lengthy screen update must be interruptable > >There must be _NO_ "lengthy screen updates". Well, I certainly agree with this, but.... Many people I know use old vt52s over phone lines. Although expensive hardware will solve this problem, creatively written software can at least make it bearable, and at a much lower cost. >> * the following commands HAVE to be single key or control keys with none of >> that vi mode switching junk: >> [...] >> * the following commands should take no more than 2 key-presses to get: >> [...] >> * DEL and ^H must both backspace > >Any editor worth its name must have the ability to bind keys in a permanent, >user-happy manner. EMACS and EVE both have all of this... User preferences >must NOT be set by The Powers That BE. While a powerful editor will let you rebind the keys, it has been my experience that most people use whatever default settings are provided. The default settings are also important for compatibilty reasons: While the special meanings of ^Q, ^S and ^O may be suppressed on some systems, they can't be controlled on others (in particular, on networked systems). Also, ^C should probably be left alone since you don't want to get people in the habbit of hitting it often (lest they get confused and forget what environment they're currenly in). Finally, I'm against having editors use ^@, ^_, ^\, ^] and even ^[ (esc) for the same reasons.
nate@hobbes.intel.com (Nate Hess) (04/06/89)
In article <1686@wpi.wpi.edu>, jhallen@wpi (Joseph H Allen) writes: >vi is 4 times less CPU hungry than emacs is. No way is all of that due to >EMACS being lispified. 4 times? Where did you get that number? I'd be interested in seeing your benchmarks. --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
jhallen@wpi.wpi.edu (Joseph H Allen) (04/08/89)
In article <3865@mipos3.intel.com> woodstock@hobbes.intel.com (Nate Hess) writes: >In article <1686@wpi.wpi.edu>, jhallen@wpi (Joseph H Allen) writes: >>vi is 4 times less CPU hungry than emacs is. No way is all of that due to >>EMACS being lispified. > >4 times? Where did you get that number? I'd be interested in seeing >your benchmarks. > Certainly: Here's the top of the 'sa' listing from my school's Encore multimax mainframe: [#calls secs real secs cpu core size program] [------ ----------- ----------- --------- -------] 714990920181100.13re 451044.24cp 11avio 7k 32452 127982.62re 91468.04cp 35avio 58k a.out 279 41175.65re 33656.60cp 231avio 1k MOPAC 31 19555.90re 16891.89cp 27avio 2k tang.exe 52 20578.62re 16483.96cp 286avio -62k 3d 5271 60848.38re 16151.23cp 43avio 0k ftp 1465 36636.23re 10989.31cp 44avio -4k macsyma 462 13825.55re 10770.85cp 6avio 0k rsa.out 76195 624754.68re 9645.13cp 62avio 0k gnu-emacs 196 10987.85re 9384.23cp 204avio 3k dr 273 10850.05re 7308.51cp 16836avio 0k save.out 20 8190.77re 7257.58cp 93260avio 0k u.out 2539 8185.82re 6504.13cp 5avio 0k test 11079 16738.35re 6142.62cp 360avio 99k data_divid 37 6615.15re 5496.17cp 6280avio -101k vortex9 1315 596559.10re 5437.55cp 42avio 0k bitfd* 22162 75731.72re 5276.16cp 61avio 0k bboard 37 7442.20re 4356.29cp 3avio 0k elegxos 3729 21597.55re 4333.92cp 52avio -85k scheme 15 4466.52re 4168.84cp 492avio 19k vent1 13054 48746.87re 4098.52cp 12avio 0k e 205584 2192733.50re 3850.42cp 8avio 0k sendmail* 15 4680.92re 3775.66cp 147avio 0k prog7 30 4497.17re 3742.22cp 159avio 0k bda 162267 5664264.98re 3700.58cp 21avio 0k csh 33015 605976.45re 3388.80cp 15avio 0k rscsd* 420 3787.57re 3283.69cp 38avio -13k b.out 117 5106.43re 3244.78cp 2avio 0k monop 474 4944.00re 3071.42cp 42avio 0k ***other 56251 3808.97re 3034.36cp 8avio 0k fcom 53 3775.92re 2996.52cp 12443avio -5k vortex3 5 3232.38re 2902.40cp 687avio -191k ven 743 5023.98re 2812.68cp 82avio 0k tasef 6339 5880.40re 2784.78cp 7avio 0k mabel 164240 223939.97re 2596.93cp 24avio 0k mail 9 3413.75re 2480.35cp 29avio 0k drequalz.e 14300 77374.25re 2463.92cp 34avio 0k nethack 25530 149623.03re 2434.80cp 229avio 0k rn 541 3824.80re 2376.03cp 3861avio 0k tube.out 40 2717.67re 2317.02cp 44062avio -59k kd 40 3599.60re 2252.66cp 25721avio 0k save1.out 486 2954.83re 2214.46cp 1avio -73k fmt_dy* 8487 45253.10re 2159.62cp 21avio 0k hack 11 2521.67re 2144.97cp 51avio 0k tang1.exe 66 4040.55re 2009.51cp 2108avio 0k vortex2 7551 3249.00re 1965.10cp 56avio 0k lastcomm 14 2651.83re 1927.65cp 20avio 0k drequal.ex 48157 2685.98re 1893.86cp 9avio 0k ccom 5 2154.97re 1805.24cp 9avio 0k fig1 169950 6392.33re 1786.44cp 24avio 0k inews 58 1923.00re 1646.43cp 5avio 0k rs3.out 349 2064.15re 1631.45cp 25avio 0k c.out 95 2087.37re 1627.74cp 32avio 0k exsyn.out 7 1737.28re 1614.59cp 234avio 0k vent 431564 402749.30re 1558.32cp 1avio 0k sh 34 1768.58re 1548.63cp 7avio 0k rs5.out 309 2125.90re 1505.15cp 13avio -71k fmt_dy 82 3682.57re 1486.00cp 90avio -57k qp 230 2029.45re 1483.01cp 40avio 0k 3dim 60201 2327.20re 1467.09cp 42avio 0k ld 28 1586.87re 1422.36cp 25avio 0k yan2 576667 2957.47re 1408.25cp 0avio 0k grep 266924 3513.67re 1371.92cp 2avio 0k ls 9 1461.85re 1368.42cp 19avio 0k mmm.out 38 1718.97re 1368.08cp 105avio 0k ray 648678 45645.02re 1363.77cp 0avio 0k sh* 3353 3319.60re 1320.71cp 715avio 0k find 71 1692.70re 1305.62cp 22avio 0k aa 10 1865.40re 1260.93cp 55avio 0k sequal.exe 127 1614.80re 1191.68cp 7avio 0k lu 26 1401.15re 1190.06cp 6avio 0k rs7.out 50 1268.60re 1183.52cp 5avio 0k rs4.out 9 1328.20re 1155.93cp 26avio 0k siproc2 6 1256.00re 1121.20cp 54064avio 0k uh.out 49 1461.25re 1106.32cp 7avio 0k rs1.out 11966 1306.72re 1074.89cp 6avio 0k mklev 4 1243.73re 1067.24cp 69avio 0k fire2 1332 1249.88re 1066.50cp 2avio 0k bye 30676 154142.85re 1043.17cp 28avio 0k vi 72859 15334.23re 1032.50cp 24avio 0k sendmail 25 1151.97re 1027.32cp 11775avio 0k unsteady [remaining 150k deleted] Sorry so long, but showing how much higher up EMACS is compared to vi is quite theatrical: CPU time per session comparison (biased towards vi since people use emacs several times per session by suspending it): emacs: cpu-secs/sessions = .127 vi: cpu-secs/sessions = .0340 emacs is 3.74 times worse. CPU time per real time (biased towards emacs since emacs gets left idle for long periods): emacs: CPU/REAL = .0154 vi: CPU/REAL = .00677 emacs is 2.27 times worse. So assuming people do similer things with emacs and vi, emacs is about 3 times worse (ok, so my 4 times estimate was a bit exaggerated :-). Actually, emacs may be 4 times as worse on other systems because on ours, the terminal servers do some of the simple editing work, but only for emacs. Other notes: the program 'e' shown above is an editor I wrote which some people are using. Unfortunately, it's currently very inefficeint because it has a timing loop (ticks are too slow) to time the terminal output data. This is so that it doesn't fill up the terminal server's output buffer so that it remains interruptable (I use it over 1200 baud phone line you see). nethack is very popular right now. MOPAC, the second top cpu time user before a.out is a chemical simulator of some kind. monopOLY crashed over christmas break.
dph@lanl.gov (David Huelsbeck) (04/09/89)
From article <1777@wpi.wpi.edu>, by jhallen@wpi.wpi.edu (Joseph H Allen): > [...] > So assuming people do similer things with emacs and vi, > emacs is about 3 times This is a very unlikely assumption unless the vast majority of your emacs users are novice users. How many of these people are using emacs to read news and mail? Are any of them using terminal emulation mode to provide themselves pseudo-windows on vt100 like terminals? God forbid you have somebody out there who likes to run hanoi with nine rings a few times a day. Even fairly simple and common activities like 'M-x compile' would up the emacs figures a lot. In a university setting where far more users are in the compile-run-edit-compile... mode than most places this sort of thing would start to add up very quickly. Since vi can't do any of this the vi users would tend to spread their cpu usage around to other utilities. You're also assuming that the distribution of users that chooses emacs is similar to that of vi users. It likely that emacs gets a distribution of users that's weighted more towards the power-user end of the spectrum. All speculation of course. I really would expect emacs to be more cpu intensive than vi. After all, one would expect a Mercedes to use more energy than a horse and buggy. What's important is what you get out for what you put in. For a new but related topic: Why are people such pussys about editors? I use emacs when I have the choice because it provideds features that I like and use that are not available on any other editor on our system. If I did not have that choice I'd use vi and lots of other things to make up for the lack of emacs. Hopefully a window system would be among them. On one system I work on we have no screen editors at all. You just learn to live with it. So what's all the bitching about? If you can't remember a few commands in whatever editor you can't remember the commands in how do you remember your password? How do you remember several programming languages at one time? -dph
usenet@TSfR.UUCP (usenet) (04/09/89)
In article <11726@lanl.gov> dph@lanl.gov (David Huelsbeck) writes: >From article <1777@wpi.wpi.edu>, by jhallen@wpi.wpi.edu (Joseph H Allen): >> So assuming people do similer things with emacs and vi, >> emacs is about 3 times >This is a very unlikely assumption unless the vast majority of your >emacs users are novice users. How many of these people are using >emacs to read news and mail? ... Via, ah, subprocesses? If emacs forks off a subprocess to read the news, it doesn't get charged for the time spent in those processes. If your emacs _is_ getting charged for that time, you'd better bitch at your system administrator, because something is rotten in the state of Denmark. >... In a university setting where far more users are in the >compile-run-edit-compile... mode than most places this sort of thing >would start to add up very quickly. Since vi can't do any of this... It's not really relevant, but it's very easy to do compiles from inside vi. :!make will do the job just fine, for instance. >... It [sic] likely that emacs >gets a distribution of users that's weighted more towards the >power-user end of the spectrum. Ahh, this is obviously some strange usage of the phrase `power user' that I was not previously aware of. -david parsons -orc@pell.uucp
amanda@iesd.dk (Per Abrahamsen) (04/09/89)
In article <519@TSfR.UUCP> usenet@TSfR.UUCP (usenet) writes: In article <11726@lanl.gov> dph@lanl.gov (David Huelsbeck) writes: >How many of these people are using emacs to read news and mail? ... Via, ah, subprocesses? No, GNU Emacs has several news and mail reader agents written in emacs lisp. Many people prefer these to the standard news and mail readers. If your emacs _is_ getting charged for that time, you'd better bitch at your system administrator, because something is rotten in the state of Denmark. Be careful, this is an international network :-). It's not really relevant, but it's very easy to do compiles from inside vi. :!make will do the job just fine, for instance. Then emacs parse the error messages, and move to the first file/line with an error. This is just a tradeoff between CPU time and human time. -- Per Abrahamsen, amanda@iesd.dk, {...}!mcvax!diku!iesd!amanda
dph@lanl.gov (David Huelsbeck) (04/10/89)
I know I shouldn't, but that's never stopped me before... From article <519@TSfR.UUCP>, by usenet@TSfR.UUCP (usenet): > Via, ah, subprocesses? If emacs forks off a subprocess to read the > news, it doesn't get charged for the time spent in those processes. > If your emacs _is_ getting charged for that time, you'd better bitch > at your system administrator, because something is rotten in the > state of Denmark. Obviously you haven't seen any of these things in action. Reading news or mail in Emacs is a lot different than doing a ':!rn' or ':!mail' in vi. The amount of processing done by non-emacs subprocesses is minimal. I wouldn't want to bitch at my sys admin anyway. Even if she does use vi. > > It's not really relevant, but it's very easy to do compiles from inside > vi. :!make will do the job just fine, for instance. > That depends on how you define 'the job'. If the job is to run make then you are correct that both editors do the job just fine. However, if you'd like to have a record of the make stored in an editor buffer where you are free to browse it and perhaps copy the information to some other buffer, or if you'd like the editor to parse the error and warning messages and move you to the point in your program where the first one was detected I think vi's going to come up a bit short. You may say "But Dave, I don't want my editor to do any of that." Fine. I work with a person who doesn't want her editor to allow her to move around with her cursor. She likes line editors. Fine. She doesn't complain about those of us who do. I don't recall that she's ever claimed that our editors were wasting cpu time. I'll bet vi uses more cpu than ed. Obviously ed is the superior product. No problems with long screen updates over slow phone lines. It's even got command mode and input mode just the way you like it! >>... It [sic] likely that emacs >>gets a distribution of users that's weighted more towards the >>power-user end of the spectrum. Well, emacs has a spelling checker but not a grammer checker. Anybody thought of writing grammer.el? Obviously though you are of superior intellect and quickly detected my horrible typo which was undoubtedly caused by the poor ergonomic features of my brain dead editor. That'll teach me to use emacs. > > Ahh, [sic] this is obviously some strange usage of the phrase `power user' > that > I was not previously aware of. > My basis for that statment was that emacs provides a number of features that are only of use if your editing demands are rather great. People writing 200 line pascal programs would have little use for windows, multiple buffers or the 'M-x compile' command. However when dealing larger, multiple source file program development these features become more attractive. So for a beginner there is no real reason to use one over the other. For a more advanced (power) user there may be. Also most intro to unix books go on at length about vi while never mentioning emacs. I know vi is standard and emacs isn't so the reason for this is obvious. I suspect that most people learn vi first and emacs second. This is perhaps the way it ought to be. Every unix user ought to be proficient enough in ed and vi to edit what ever they might need to edit. There are times when this comes in handy. If need be I can do long division but I'd rather use a calculator when I can. > -david parsons > -orc@pell.uucp -dph
las) (04/11/89)
In article <1777@wpi.wpi.edu> jhallen@wpi.wpi.edu (Joseph H Allen) writes: }In article <3865@mipos3.intel.com> woodstock@hobbes.intel.com (Nate Hess) writes: }}In article <1686@wpi.wpi.edu>, jhallen@wpi (Joseph H Allen) writes: }}>vi is 4 times less CPU hungry than emacs is. No way is all of that due to }}>EMACS being lispified. }}4 times? Where did you get that number? I'd be interested in seeing }}your benchmarks. }Here's the top of the 'sa' listing from my school's Encore multimax mainframe: [omitted] }CPU time per session comparison (biased towards vi since people use emacs }several times per session by suspending it): } }emacs: cpu-secs/sessions = .127 }vi: cpu-secs/sessions = .0340 }emacs is 3.74 times worse. }CPU time per real time (biased towards emacs since emacs gets left idle for }long periods): }emacs: CPU/REAL = .0154 }vi: CPU/REAL = .00677 }emacs is 2.27 times worse. This is hardly a devastating indictment of Emacs. It's not even as "bad" as I thought it might be. I can and do use vi because I must, but personally, I like what Emacs has to offer and the fact that it uses more resources than vi is neither surprising nor distressing to me. Let the computers do the work, that's what they're there for. Now if Emacs used 50 or 100 times the resources that vi requires, the efficiency argument could be very important, but I ordinarily do not care how hard computers have to work (I know, I know, your academic computing environment is overloaded and unusable, but a difference of less than one order of magnitude in the use of computer resources probably won't give you meaningful relief). If your system is overloaded, I am sympathetic - I just don't think that "efficiency" is the main point to consider when selecting a utility as important as an editor. If it were, why not use "cat" as proposed elsewhere in this thread? regards, Larry -- Signed: Larry A. Shurr (att!cbnews!cbema!las) Clever signature, Wonderful wit, Outdo the others, Be a big hit! - Burma Shave (With apologies to the real thing. The above represents my views only.) (Please note my mailing address. Mail sent to me on cbnews doesn't make it.)
schmidt@cadlab.uucp (Michael Schmidt) (04/12/89)
In article <16732@mimsy.UUCP>, chris@mimsy (Chris Torek) writes: >>In article <1686@wpi.wpi.edu> jhallen@wpi.wpi.edu (Joseph H Allen) notes >>> * every lengthy screen update must be interruptable > >In article <11473@lanl.gov> mikeg%watson.c3@lanl.gov (M.P.Gerlek) writes: >>There must be _NO_ "lengthy screen updates". > >At 300 baud, *every* screen update is lengthy. You have made an impossible >demand. Not with GNU Emacs and a reasonable intelligent terminal (e.g. multiple insert/delete character/line). I used it some time ago and I could really work with 300 Baud. -- Michael Schmidt, CADLAB / FB 17, Uni-GH Paderborn, Bahnhofstr. 32, D-4790 Paderborn, West Germany Mail: schmidt@cadlab.UUCP or schmidt@cadlab.cadlab.de
jpdres10@usl-pc.usl.edu (Green Eric Lee) (04/14/89)
In article <1777@wpi.wpi.edu> jhallen@wpi.wpi.edu (Joseph H Allen) writes: >In article <3865@mipos3.intel.com> woodstock@hobbes.intel.com (Nate Hess) writes: >[#calls secs real secs cpu core size program] > 76195 624754.68re 9645.13cp 62avio 0k gnu-emacs > 30676 154142.85re 1043.17cp 28avio 0k vi >[remaining 150k deleted] Comparing VI and Emacs in terms of CPU time used is theatrical, yes, but somewhat like comparing apples and potatoes. It will always be cheaper to directly control the screen than to go through a windowing environment with smart refresh capability, but some people appreciate having a windowing environment available (and, over current phone lines with 1200-2400 baud, a text terminal is the only way to get decent throughput without a LOT of expensive smarts at the terminal end). Similarly, it will always be cheaper to dispatch directly to the "C" routine rather than using reconfigurable keymaps and Lisp functions -- but some people (though not as many) appreciate having the power of a full programming language in their text editor. From looking at the various MicroEmacs editors, which do not have the Lisp dispatch overhead, I have come to the conclusion that most of the CPU time spent by Emacs is in the windowing/screen-redisplay code. I would have to profile Emacs to see if I'm correct (and profiling GNU Emacs is not an exercise for the faint-of-heart), but an interesting observation is to run both MicroEmacs and GNU Emacs side-by-side on a heavily loaded machine, and start typing keys at each one. MicroEmacs will stutter and halt more than GNU Emacs -- unexpected, to say the least. This implies that a) the Gosling screen redisplay algorithm is very CPU-intensive (which Gosling himself said in his paper), and b) GNU Emacs has a relatively efficient implementation of that CPU-intensive routine. That's not even counting the synchronization code necessary when it is possible to have two or more windows into the same file. Will the byte that you're currently typing in window 'A' affect what's currently displayed in window 'B'? It'll always be more efficient to simply say, "Nope, can't display multiple windows", and directly control the screen, rather than have all sorts of checking code for special cases like this. >So assuming people do similer things with emacs and vi, emacs is about 3 times >worse (ok, so my 4 times estimate was a bit exaggerated :-). Actually, emacs >may be 4 times as worse on other systems because on ours, the terminal servers >do some of the simple editing work, but only for emacs. 3 times worse for what? I don't use Emacs often anymore, since I do most of my work on PCs now, but when I use Emacs, it's not likely to be for simple text entry. I'm no VI expert, but even I find it faster to pull up VI to enter masses of text, than to use Emacs. I often read news using Emacs (the code is written in Emacs Lisp, meaning the CPU is charged to Emacs), and often read/reply to mail using Emacs (again, code in Emacs Lisp). I often use the "dired" feature to scroll back and forth in a list of files, a feature especially helpful when I'm trying to clean up a bunch of little netnews files that I saved to my News directory (I can hit "o", look at it in the other window, say "hmm, don't need that", switch window, zap it, next). I sometimes even run a couple of shells in Emacs windows, when I want to watch two processes going on at the same time without having to redirect the output of one. The point of the above is that I use Emacs for a lot of things beside text editing -- and that attributing all of Emac's CPU usage to its "inefficiency" as a text editor is ignoring the way that it is usually used, i.e., as a cheap windowing environment for text-only terminals. -- | // Eric Lee Green P.O. Box 92191, Lafayette, LA 70509 | | // {uunet!dalsqnt,killer}!usl!elg (318)989-9849 | | \X/ >> In Hell you need 4Mb to Multitask << |
woods@tmsoft.uucp (Greg Woods) (04/18/89)
I'm a heavy user of several variations of "micro-emacs'". I prefer Jove, but am using mg (MicroGnuEmacs) right now. In article <267@usl-pc.usl.edu> jpdres10@usl-pc.UUCP (Green Eric Lee) writes: >In article <1777@wpi.wpi.edu> jhallen@wpi.wpi.edu (Joseph H Allen) writes: >>In article <3865@mipos3.intel.com> woodstock@hobbes.intel.com (Nate Hess) writes: >>[#calls secs real secs cpu core size program] >> 76195 624754.68re 9645.13cp 62avio 0k gnu-emacs >> 30676 154142.85re 1043.17cp 28avio 0k vi >>[remaining 150k deleted] > >[....] > >From looking at the various MicroEmacs editors, which do not have the >Lisp dispatch overhead, I have come to the conclusion that most of the >CPU time spent by Emacs is in the windowing/screen-redisplay code. Since this is most of what is necessary during normal text entry and simple editing, this is to be expected of a full-screen, interactive text editor. Especially one which attempts to be smart about how many characters it sends to the terminal. >[....] an interesting >observation is to run both MicroEmacs and GNU Emacs side-by-side on a >heavily loaded machine, and start typing keys at each one. MicroEmacs >will stutter and halt more than GNU Emacs -- unexpected, to say the >least. This implies that a) the Gosling screen redisplay algorithm is >very CPU-intensive (which Gosling himself said in his paper), and b) >GNU Emacs has a relatively efficient implementation of that >CPU-intensive routine. First, GNU-Emacs doesn't seem to use the Gosling re-display algorithm, and certainly doesn't use Gosling's code (I've never seen the skull and crossbones in GNU-Emacs, and the style is completely different). Second, you've got to be very careful which "micro-emacs" you are testing. Mg is one variation of the original Conroy MicroEmacs, and seems to have kept most of the simple re-display code. It's not very smart, but probably doesn't waste much CPU either. The Lawrence version of MicroEmacs was also quite simplistic up to v3.7. I've not paid much attention to it since then, but I doubt it's much better, since I've seen it stumble in all the places it used to. I'd bet people have spent more time fixing some of the bad bugs and adding the macro language than improving the display code. Jove is considerably smarter than either the early MicroEmacs or mg. However it does seem to be a bit more of a CPU hog. (I've not actually done any comparisons, but many hours of work on both, while sitting next to the machine (i.e. listening to the disk), it seems Jove slows a bit more under heavier machine load.) The only GNU-Emacs I've had experience with was 17.52 or some such version, and though it did seem to be a bit smarter than the rest, that version had a lot of bugs. I haven't used Gosling Emacs since long before it was available through UniPress, and though I've read the skull&bones code, I can't remember enough to make a logical comparison, except to say it was a hell of a lot smarter than MicroEmacs3.7. Of course all of the "micro-emacs'" versions I've seen use linked lists to store the text. I think this makes it much easier to write good smart display update code. *** opinion follows *** If you are looking for a good "micro-emacs", I'd suggest Jove4.12 (not easy to port to SysV, but hopefully the next version will be). It has most of the features I've ever used in an emacs except Lisp. -- Greg A. Woods. woods@{{tmsoft,utgpu,gate,ontmoh}.UUCP,utorgpu.BITNET,gpu.utcs.Toronto.EDU} +1-416-443-1734 [h], +1-416-595-5425 [w] Toronto, Ontario, Canada