[net.emacs] Is Gosling's EMACS really slow or what ?

dan@rna.UUCP (Dan Ts'o) (08/14/84)

Hi,
	We are using Gosling's EMACS on a VAX 750. It seems very slow
compared to VI or JOVE. Is there something we're doing wrong ? Just simple
cursor motion seem to hang up and don't have a snappy response even in
single-user mode. How does CCA EMACS compare ?

					Cheers,
					Dan Ts'o
					...cmcl2!rna!dan

chris@umcp-cs.UUCP (08/15/84)

Well, the old version of Emacs (#85 and before) used floating point in
its screen update algorithm.  That tends to slow down a 750 a lot.
Also, in pre-UniPress releases, the window optimization code gave up
on anything harder than one-line or one-window optimizations.  #264
Emacs has Gosling's fixedpoint code in display.c and his new fancier
window optimizations, which handle cursor up&down motions (as long
as lines don't wrap) as well as left&right motions.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci (301) 454-7690
UUCP:	{seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@maryland

phil@amd.UUCP (Phil Ngai) (08/16/84)

I once looked at CCA emacs (it was a couple of years old) and
was horrified to find it stored all the error msgs in the program.
The text was about 180K. What's worse, it allocated about 900K
of bss. Needless to say, it was very slow to start up.

-- 
 amd70 is dead, tell a friend
 Phil Ngai (408) 982-6554
 UUCPnet: {ucbvax,decwrl,ihnp4,allegra,intelca}!amd!phil
 ARPAnet: amd!phil@decwrl.ARPA

z@cca.UUCP (Steve Zimmerman) (08/20/84)

Phil Ngai brought up some points that I think were somewhat misleading,
so I think I should clarify the record.

Although CCA EMACS once had certain error and documentation messages
compiled into the program, these were all moved out into separate files
about two years ago, well before the first commercial release of the
program.  Also, the current bss storage is 420K, not 900K, and this can
be further reduced for small memory configurations.  However, the amount
of bss storage required in no way affects the startup time of a program,
as the bss simply reflects the amount of memory that is reserved for
later use by the program.

In terms of startup time, CCA EMACS takes about three seconds to come
up on a Sun, using average size initialization files.  As for
efficiency, we have measured the effect of ten people using CCA EMACS on
a VAX 11/780 with nothing else happening; the load average remained
under one.

	Steve Zimmerman
	CCA Uniworks

phil@amd.UUCP (Phil Ngai) (08/22/84)

In my article I mentioned that the copy of CCA emacs I saw was
pretty old and assumed people would understand that it might
have been improved since then. Efficiency considerations aside,
I did like what I saw and thought it was a good product. It sounds like
Steve has improved on what I saw and made it into an even better product.

-- 
 Welcome to California.
 Now go home.

 Phil Ngai (408) 982-6554
 UUCPnet: {ucbvax,decwrl,ihnp4,allegra,intelca}!amd!phil
 ARPAnet: amd!phil@decwrl.ARPA

andrew@orca.UUCP (Andrew Klossner) (08/23/84)

[]

	"However, the amount of bss storage required in no way affects
	the startup time of a program, as the bss simply reflects the
	amount of memory that is reserved for later use by the
	program."

I wish this were so, but in fact startup time includes a component
which is linear with the size of the entire program (text+data+bss)
because the system has to preallocate that much swap space.

I regularly run a program with 200k text, 50k data, and bss larger than
1Meg.  The effect of large bss upon startup time is quite noticeable.

This is all under 4.2BSD.

  -- Andrew Klossner   (decvax!tektronix!orca!andrew)      [UUCP]
                       (orca!andrew.tektronix@rand-relay)  [ARPA]

z@cca.UUCP (Steve Zimmerman) (08/25/84)

[]

      "I regularly run a program with 200k text, 50k data, and bss larger than
      1Meg.  The effect of large bss upon startup time is quite noticeable."

For measurement purposes, I've run CCA EMACS with a total size of over 1
megabyte as well.  Although the program takes several seconds to start
up, I know that it begins to execute its initialization routines within
a half second of starting because these routines send strings to the
terminal that can be displayed on terminals with monitor facilities.  At
this point, a fair amount of code has already been executed, so the real
load time is probably under half a second.  Compared to the overall
initialization time of several seconds, this does not seem very
significant.

	Steve Zimmerman