Path: utzoo!utgpu!attcan!uunet!yale!Ram-Ashwin
From: Ram-Ashwin@cs.yale.edu (Ashwin Ram)
Newsgroups: comp.emacs
Subject: Re: Building Emacs for Apollo; runs sloooooow
Keywords: emacs apollo SR9.7 DN660
Message-ID: <34922@yale-celray.yale.UUCP>
Date: 4 Aug 88 01:34:11 GMT
References: <1410@turbinia.oakhill.UUCP>
Sender: root@yale.UUCP
Reply-To: Ram-Ashwin@cs.yale.edu (Ashwin Ram)
Distribution: na
Organization: Computer Science, Yale University, New Haven, CT 06520-2158
Lines: 41
In-reply-to: abair@oakhill.UUCP (Alan Bair)

In article <1410@turbinia.oakhill.UUCP>, abair@oakhill (Alan Bair) writes:
> I am having problems running Emacs on the Apollo. [...]
> I am using Emacs 18.51 with config.h having s-bsd-4.2.h & m-apollo.h.
> [...]                                                      The Apollo
> is an DN660 with 8MB real, but <20MB free disk space (swap space
> shortage mentioned in notes).  I just upgraded to SR9.7 from SR9.2.3,

We are running GNU Emacs 18.48 on our Apollo DN3000's running SR 9.7 with no
real problems.

> As I said the build worked fine, no errors.  Of course the Apollo
> cannot build a dumped version.

18.48 was hacked by Leonard Zubkoff to allow dumping.  He also added GPR support
so that Emacs runs in a GPR window rather than under the vt100 emulator.  Loadup
and screen update is fast.

>                                 So when I start it up, all the lisp
> code is loaded in and then it displays the normal introduction screen.
> Then things go down hill.  I can enter a single command like C-x C-b,
> but it may take several minutes before it does anything.  The next
> command I try just goes away, no response for >5 minutes.  If I check
> cpu usage, its got >90%, looks like its looping.  At this point I 
> kill it from another window and give up.

If you're running it off another node on a ring of Apollos, the response time of
the ring or of the remote node could be affecting the speed.  I also found that
file locking takes a long time due to the necessity of accessing remote lock
files, and doesn't work correctly anyway since Emacs doesn't know about DM's own
locks.  I built a version without file locking and got a significant improvement
in file operations (visiting files, verifying their modtime, etc.)

Even before Zubkoff's version we didn't encounter any problems like the ones you
mention with C-x C-b.  You might try using the utilities in /systest/ssr_util
(e.g., ringlog) or /com/dspst to try to figure out where the bottleneck is.

-- Ashwin.

ARPA:    Ram-Ashwin@cs.yale.edu
UUCP:    {decvax,ucbvax,harvard,cmcl2,...}!yale!Ram-Ashwin
BITNET:  Ram@yalecs