From xemacs-m  Sun Dec 15 23:03:59 1996
Received: from mailhost.lanl.gov (mailhost.lanl.gov [128.165.3.12]) by xemacs.cs.uiuc.edu (8.8.3/8.8.3) with ESMTP id XAA20981 for <xemacs-beta@xemacs.org>; Sun, 15 Dec 1996 23:03:58 -0600 (CST)
Received: from xdiv.lanl.gov (xdiv.lanl.gov [128.165.116.106]) by mailhost.lanl.gov (8.8.4/8.8.3) with ESMTP id WAA27003 for <xemacs-beta@xemacs.org>; Sun, 15 Dec 1996 22:04:00 -0700 (MST)
Received: from branagh.lanl.gov (branagh.lanl.gov [128.165.16.72]) by xdiv.lanl.gov (8.6.12/8.6.12) with ESMTP id WAA26043; Sun, 15 Dec 1996 22:04:02 -0700
Received: by branagh.lanl.gov (SMI-8.6/SMI-SVR4)
	id WAA02208; Sun, 15 Dec 1996 22:01:49 -0700
Date: Sun, 15 Dec 1996 22:01:49 -0700
Message-Id: <199612160501.WAA02208@branagh.lanl.gov>
From: John Turner <turner@xdiv.lanl.gov>
To: xemacs-beta@xemacs.org
Subject: Re: 19.15-b4 bench results
In-Reply-To: <m2engrfgsj.fsf@altair.xemacs.org>
References: <199612160002.RAA28973@branagh.lanl.gov>
	<m2engrfgsj.fsf@altair.xemacs.org>
Reply-To: turner@lanl.gov

Steven L. Baur writes:

 > It looks like you compiled under greater optimization.  

Yes.  19.14 was the generic precompiled stuff, 19.15-b4 I compiled
with UltraSPARC-specific optimizations.  I was just interested in how
much difference they made.

 > You left one
 > thing out.  Did the display lock up?  

I guess I did forget to mention that I never had any problems running
the benchmarks with -q.  Yeah, that was my main point, that something
(or some combination of things) I'm using is really making things
pokey.

 > Try stripping all but the Tower
 > of Hanoi and Large File scrolling, and running (bench 5) or (bench 10).

OK, I'll let you know.

 > John> First of all, it's obvious that at least some aspects of my
 > John> "loaded" XEmacs are considerably slower than the stripped-down
 > John> one.  Hanoi is slower by a factor of 2.5x, font-lock by 2x,
 > John> frame creation by 2x, etc.
 > 
 > Fascinating.  But be sure to run the tests multiple times.  elp uses
 > wallclock times, and if your system was under different levels of
 > load, that alone could count for the variation.

I'm the only one on, and nothing else was happening (I was using
another machine most of the time).

 > Keep turning things off then.  If it isn't lazy-lock, or func-menu it
 > must be something else then.  I hope what you meant by `turned off',
 > was exiting the program, commenting out the lines in .emacs that turn
 > on the specific package and restarting.  All bets are off otherwise.

Definitely.  Everything from clean starts.

 > If you didn't lock up when running in a naked environment, but you did
 > when your .emacs is loaded, then you need to isolate which package is
 > doing the damage.
 > 
 > I think if we only get as far as isolating that, it would be an
 > enormous improvement.

I know.  I don't look forward to doing this.  If I had finished this
msg before my recompile with --debug=no finished I was going to go
home.  But the rebuild just finished, so I guess I'll play with it
some...

--
John A. Turner         |"Music is the cup which holds the wine of silence;
Los Alamos Natl. Lab.  |  sound is that cup, but empty;
e-mail: turner@lanl.gov|    noise is that cup, but broken."
                       |                        - Robert Fripp

