nate@hobbes.intel.com (Nate Hess) (04/10/89)
In article <1777@wpi.wpi.edu>, jhallen@wpi (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. >Certainly: >[#calls secs real secs cpu core size program] >[------ ----------- ----------- --------- -------] > 76195 624754.68re 9645.13cp 62avio 0k gnu-emacs [deleted numerous lines] > 30676 154142.85re 1043.17cp 28avio 0k vi >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. Your use of the word "worse" is most interesting. As a single example, Emacs has a command to reformat paragraphs. Vi users have to call the Unix "fmt" command. Your statistics don't reflect this. Nor do they consider the fact that Emacs users can get on-line help during their editing, something unavailable in vi. >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. Once again, your use of the word "worse". Your statistics could just as easily prove that Emacs users are more productive than vi users. >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. I claim that this is a bad assumption. I also claim that arguing about editing efficiency by siting amounts of CPU time used by Emacs and vi is misleading. If you're editing a file in vi, one you've made significant changes to, and you need to take a peek at another file to look up a variable name or some such, the only way to do it without first saving the file is to C-z out, vi the other file, and then fg back to the original vi. If you're using Emacs in the above scenario, you simply pull up the file in another window, find what you want, and then enter text in the original file while still looking at the other one. Vi users tend to "vi filename", perform some editing tasks, and then exit vi, repeating as often as necessary. Emacs users tend to invoke Emacs once when they login, and keep that Emacs fired up until they logout. The greater functionality of Emacs encourages users to do more things with it; merely stating that Emacs gobbles up 3 times the CPU resource that vi does is missing the point. --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
gaynor@athos.rutgers.edu (Silver) (04/15/89)
The points nate@hobbes.intel.com makes are valid. The timings most likely do not the time used by subprocesses (and definitely not programs run during a temporary suspension) by the two editors, do they? (Please correct me post haste if I'm mistaken, so I can start talking out of a different side of my mouth!). GNU Emacs is a totally different animal than vi. It is an order of magnitude more functional, and performs a lot more intelligently than it's usually given credit for. I wouldn't be surprised to find that a significant portion of time is spent making frequent checkpoints and backups. I wouldn't be surprised to find that a significant portion of time is spent justifying text, which would have to otherwise be done by another process. Etc. I wonder if it's even possible to write a decent interface to another process in vi. Now, if you get all that extra functionality at a mere 4 times the cost, even 10 time the cost, you've got a tremendous bargain. Regards, [Ag] gaynor@rutgers.edu