dan@lclark.UUCP (Dan Revel) (08/10/88)
Does anyone know what sort of impact jove has on system performance? We're running Bsd 4.3 on a VAX 11/750 and I'd like to know what's going to happen to our response time if all of a sudden ( this fall ) we have 10-15 people on the system using jove ( as opposed to vi ). My suspicion is that things will run a bit slower, but how much? thanks, -- dan@lclark tektronix!reed!lclark!dan Dylsexics untie! (-|
madd@bu-cs.BU.EDU (Jim Frost) (08/10/88)
In article <282@lclark.UUCP> dan@lclark.UUCP (Dan Revel) writes: |Does anyone know what sort of impact jove has on system performance? Very little for average use. It's not a very big or complex program and it doesn't do very much. |We're running Bsd 4.3 on a VAX 11/750 and I'd like to know what's |going to happen to our response time if all of a sudden ( this fall ) |we have 10-15 people on the system using jove ( as opposed to vi ). |My suspicion is that things will run a bit slower, but how much? I don't think it will run appreciably slower (maybe not even noticably), although I can't really be sure since I haven't seen the code for vi to see how it does things. I would not recommend using jove, however. The version that I tried to port to SysV on a Silicon Graphics 4D had some more-than-ugly code; I don't trust it anymore. You might look into microemacs, which is more portable than jove, more functional, and is still quite small and quick. That should also have little effect on system performance. BTW, 15 people on a 11/750 is going to be very, very slow no matter what editor you're using. jim frost madd@bu-it.bu.edu
woods@gpu.utcs.toronto.edu (Greg Woods) (08/11/88)
In article <24356@bu-cs.BU.EDU> madd@bu-it.bu.edu (Jim Frost) writes: >In article <282@lclark.UUCP> dan@lclark.UUCP (Dan Revel) writes: >|Does anyone know what sort of impact jove has on system performance? > >Very little for average use. It's not a very big or complex program >and it doesn't do very much. It get's one of the lowest "hog" factors from sar on 386/ix. > I would not recommend using >jove, however. The version that I tried to port to SysV on a Silicon >Graphics 4D had some more-than-ugly code; I don't trust it anymore. >You might look into microemacs, which is more portable than jove, more >functional, and is still quite small and quick. That should also have >little effect on system performance. Jove4.9 is a superb piece of work, unlike the mess that makes up MicroEmacs. Not only is it written much better, but the code is more reliable, and it has more features. I used and hacked MicroEmacs up to the days of 3.7, and then found Jove. I'll never go back. I won't even try and find a copy of my sources to let people try and fix bugs that still persist since the Dave Conroy days, in both major diversions of MicroEmacs: MicroEmacs, and MicroGNU. The only "ugly-ness" in Jove has to do with the fact that it replaces a good part of the stdio library, for some VERY good reasons. This also generates some portability problems, though it is MUCH more portable than your average stdio. The only remaining bug I thought Jove4.9 had has turned out to be a bug in the Xenix V 286 2.2.1 compiler. As it has also turned out, Jove is more portable than MicroEmacs. I've already mentioned the functionality. Jove easily ports to most any version of Unix, and now runs on MS-DOS and the Mac. Hopefully the version you had was quite old. >BTW, 15 people on a 11/750 is going to be very, very slow no matter >what editor you're using. :-) >jim frost >madd@bu-it.bu.edu -- Greg Woods. UUCP: utgpu!woods, utgpu!{ontmoh, ontmoh!ixpierre}!woods VOICE: (416) 242-7572 [h] LOCATION: Toronto, Ontario, Canada
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (08/17/88)
In article <1988Aug10.203225.26885@gpu.utcs.toronto.edu> woods@gpu.utcs.Toronto.EDU (Greg Woods) writes: | It get's one of the lowest "hog" factors from sar on 386/ix. Be careful of the hog factor on editors. The speed of the user and the use of macros can allow use of a lot of CPU in a short time. This might make an argument for an editor which didn't have macros or repeated command, since it would slow the user. You sometimes see a high hog factor on vi jobs doing a lot of global replace. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
mikep@ism780c.isc.com (Michael A. Petonic) (08/17/88)
In article <11873@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: >In article <1988Aug10.203225.26885@gpu.utcs.toronto.edu> woods@gpu.utcs.Toronto.EDU (Greg Woods) writes: >| It get's one of the lowest "hog" factors from sar on 386/ix. > > Be careful of the hog factor on editors. The speed of the user and the >use of macros can allow use of a lot of CPU in a short time. This might >make an argument for an editor which didn't have macros or repeated >command, since it would slow the user. Wait a minute. That's like saying: ``Might as well be editing with "ed" since it would slow the user.'' -MikeP -- Michael A. Petonic mikep@ism780c.isc.com ``When was the last time you dug a ditch, baby?''
katz@itivax.UUCP (James Katz) (08/19/88)
We have 15 -20 users who use jove on an 11/785 without any performance problem. vi seems to affect performance more than jove.