From xemacs-m  Sat Feb  8 15:35:45 1997
Received: from martigny.ai.mit.edu (martigny.ai.mit.edu [18.43.0.152])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id PAA08896
	for <xemacs-beta@xemacs.org>; Sat, 8 Feb 1997 15:35:44 -0600 (CST)
Received: from berne.ai.mit.edu by martigny.ai.mit.edu with SMTP
	(1.40.112.8/16.2) id AA176887731; Sat, 8 Feb 1997 16:35:31 -0500
From: Bill Dubuque <wgd@martigny.ai.mit.edu>
Message-Id: <199702082135.AA176887731@martigny.ai.mit.edu>
Received: by berne.ai.mit.edu
	(1.40.112.8/16.2) id AA009557730; Sat, 8 Feb 1997 16:35:30 -0500
Date: Sat, 8 Feb 1997 16:35:30 -0500
To: kyle_jones@wonderworks.com
Cc: xemacs-beta@xemacs.org
In-Reply-To: <QQccax12138.199702081959@crystal.WonderWorks.COM> (message from
	Kyle Jones on Sat, 8 Feb 1997 14:59:37 -0500 (EST))
Subject: Re: wot i need

: Date: Sat, 8 Feb 1997 14:59:37 -0500 (EST)
: From: Kyle Jones <kyle_jones@wonderworks.com>
: 
: This loop, uncompiled, runs about twice as fast under FSF Emacs
: as it does under XEmacs 20.0.  Why?
: 
: (let ((i 0)) (while (< i 300000) (setq i (1+ i))))
: 
: If we can find out and solve it, I have a feeling we could go a
: long way toward speeding up XEmacs.  Look at that loop.  No
: consing, nothing but subrs called, no magic symbols, no buffer local
: variables.  What is it that XEmacs is doing twice as much of to
: get the same result?

Perhaps QUIT is slower in XEmacs vs. FSF. 

QUIT is executed each time eval is calle, hence during the eval
of <, setq, 1+ in each loop iteration.  Additionally, XEmacs 
will call QUIT one more time per loop because, unlike FSF,
its setq calls length, which does a QUIT. I recall that Ben
did a lot of work on QUIT, so it might be much hairer in XEmacs
vs. FSF.

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.

Did you run the tests so to factor out any consing, e.g. with
gc-cons-threshold huge? (there shouldn't be any consing, but 
who knows). Also, did you disable any timers or other interrupt
driven code that might be running?

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.

-Bill Dubuque

