On Mon, 6 Sep 1999, Michael Kukat wrote:
> On Mon, 6 Sep 1999, Super-User wrote:
> > On Fri, Sep 03, 1999 at 07:30:26AM -0700, Brian D Chase wrote:
> > > On Fri, 3 Sep 1999, J.S. Havard wrote:

> > > > Might not be practical to run due to resource constraints...  Wouldn't
> > > > happen to be talking aobut emacs by any chance?
> > > 
> > > Nah, emacs actually runs pretty well, even on my MicroVAX II.  It takes a
> > > little while to load -- 15-20 sec, but is quite responsive once loaded.
> > > The size in memory just after loading is 3212KB, so it's actually pretty
> > > tight.

[Correction: it's 30sec to load when it's not been not cached from disk,
 about 17sec when it has been cached.]

> > Mozilla 4 on an UltraSparc 10 (300 MHz clock) needs a bit less to load.
> > Only 12 seconds.

> With 2 Ultrasparcs @300 MHz it takes not even this. (Netscape Navigator 4.6)

Well, lynx takes 20sec to load on my MicroVAX II.  It'd be curious to see
how Mozilla fares on the same system. :-)

Back to the topic of VAXen, I've been having some problems under 1.4.1
compiling large C source files.  Bascially I'm running into the hard 24MB
limit on process datasize.  Seems pretty insane yes, but there's one file
in the imlib package which when I compile it, egcs runs out of virtual
memory.  This happens even when I disable optimizations.  I know I can go
in an fix the source to set this hard limit to suit my needs, and I will
do so in a kernel geared towards compiling things.

Still, for the 1.5 release or maybe even the 1.4.2 release if there will
be one, we should perhaps consider upping the default datasize per process
to be 32MB or maybe 48MB.  We've got some big packages under pkgsrc, and
if we're going to want to run KDE on our VAXstation 2000s, we're going to
need to be able to support really memory hungry processes.

-brian.
---
Brian "JARAI" Chase | http://world.std.com/~bdc/ | VAXZilla LIVES!!!