From xemacs-m  Sat Feb  8 16:14:21 1997
Received: from crystal.WonderWorks.COM (crystal.WonderWorks.com [192.203.206.1])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id QAA09376
	for <xemacs-beta@xemacs.org>; Sat, 8 Feb 1997 16:14:17 -0600 (CST)
Received: by crystal.WonderWorks.COM 
	id QQccbg17114; Sat, 8 Feb 1997 17:14:13 -0500 (EST)
Date: Sat, 8 Feb 1997 17:14:13 -0500 (EST)
Message-Id: <QQccbg17114.199702082214@crystal.WonderWorks.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Kyle Jones <kyle_jones@wonderworks.com>
To: Bill Dubuque <wgd@martigny.ai.mit.edu>
Cc: xemacs-beta@xemacs.org
Subject: Re: wot i need
In-Reply-To: <199702082135.AA176887731@martigny.ai.mit.edu>
References: <QQccax12138.199702081959@crystal.WonderWorks.COM>
	<199702082135.AA176887731@martigny.ai.mit.edu>

Bill Dubuque writes:
 > Perhaps QUIT is slower in XEmacs vs. FSF.

It is hairier under XEmacs, but most of the time (all of the time
in my loop) it doesn't involve function calls.  I defined it as
do {} while (0) and rebuilt XEmacs.  The loop ran about 7%
faster.

 > [...]
 > Another possibility is that FSF doesn't have floating-point code
 > compiled in, so arith ops are slightly faster. But this shouldn't
 > make that much difference.

My FSF Emacs binary does have the floating point code.

 > Did you run the tests so to factor out any consing, e.g. with
 > gc-cons-threshold huge?

Yes.  I left it out of my message but I did (for some reason)
have it set to 10 million in my test.

 > (there shouldn't be any consing, but who knows). Also, did you
 > disable any timers or other interrupt driven code that might
 > be running?

I ktrace'd the process during a run and no interrupts happened.
Under BSD/OS, XEmacs uses select(), thank God, so there's no
SIGIO going on (I hope).

 > If the culprit is QUIT, or some other similar thing thats getting
 > called a few times per iteration then its unlikely to have any 
 > importance in real code. The only reason you see it above is that
 > the while body is trivial and executes in time comparable to
 > the QUIT call. In nontrivial loops the incremental extra time
 > taken by QUIT would be overwhelmed by the time taken by the
 > rest of the while body. Why don't you try the same test with less
 > trival while bodies.

I would agree, except I started looking at this because I noticed
that FSF Emacs loads vm.elc twice as fast as XEmacs.  So either
the reader or the evaller or the allocator or all three are
slower.  So I wrote this loop to test the evaller without 
extraneous factors.  I got the same two to one speed difference.
Not conclusive, but definitely suspicious.

