Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uunet!cs.utexas.edu!rice!sun-spots-request
From: apple!kla!pat@decwrl.dec.com (Pat Lashley)
Newsgroups: comp.sys.sun
Subject: Re: SunOS 4.0 and memory
Keywords: Miscellaneous
Message-ID: <4028@brazos.Rice.edu>
Date: 20 Dec 89 01:19:52 GMT
Sender: root@rice.edu
Organization: Sun-Spots
Lines: 20
Approved: Sun-Spots@rice.edu
X-Refs:  Original: v8n196, Replies: v8n199 v8n206 v8n212
X-Sun-Spots-Digest: Volume 8, Issue 230, message 1 of 13

In article <3272@brazos.Rice.edu> auspex!guy@uunet.uu.net (Guy Harris) writes:
>X-Sun-Spots-Digest: Volume 8, Issue 206, message 7 of 15
>
>I find the performance acceptable, although it could certainly be better.
>I run compiles on my machine; it does have some impact on the other
>"shelltool" (usually logged into a 4/280 here), ...

I tend to be a workstation `power user' - multiple shelltools, GNU emacs
with ispell and emacs-server processes, continuous mailtool, perfmeters,
etc.; I also tend to use the GNU/FSF (memory is cheap, and getting
cheaper...) versions of various utilities.  While first testing X/NeWS on
a color 386i (Beta-1 was significantly slower than the final release :-),
I discovered a very simple (almost too obvious to see) method for
preventing compiles from degrading the interactive performance of other
windows.  It should work for (almost) any windowing system.  Our old
friend nice(1).  Where `make foo' would bring even mouse tracking to a
near standstill; `nice make foo' hardly affected interactive performance
at all.

-Pat