From xemacs-m  Mon Dec 16 11:34:33 1996
Received: from atreides.mindspring.com (qmailr@atreides.mindspring.com [204.180.142.236]) by xemacs.cs.uiuc.edu (8.8.3/8.8.3) with SMTP id LAA24534 for <xemacs-beta@xemacs.org>; Mon, 16 Dec 1996 11:34:32 -0600 (CST)
Received: (qmail 1365 invoked by uid 52477); 16 Dec 1996 17:34:27 -0000
Sender: sj@atreides.mindspring.com
To: XEmacs beta <xemacs-beta@xemacs.org>
Subject: Re: 19.15-b4 bench results (Hanoi)
References: <199612160002.RAA28973@branagh.lanl.gov> 	<m2engrfgsj.fsf@altair.xemacs.org> 	<199612160501.WAA02208@branagh.lanl.gov> 	<199612160646.XAA02372@branagh.lanl.gov> 	<199612160657.XAA02385@branagh.lanl.gov> <199612161619.JAA03083@branagh.lanl.gov> <m2ohfu5rlb.fsf@altair.xemacs.org>
From: Sudish Joseph <sudish@mindspring.com>
Date: 16 Dec 1996 12:34:27 -0500
In-Reply-To: Steven L Baur's message of 16 Dec 1996 09:25:36 -0800
Message-ID: <yviazpzepf4s.fsf@atreides.mindspring.com>
Lines: 20
X-Mailer: Red Gnus v0.74/XEmacs 20.0

In article <m2ohfu5rlb.fsf@altair.xemacs.org>,
Steven L Baur <steve@miranova.com> writes:
> The question of why display-time slows things down so much still needs
> to be answered.  I see it using itimer, and that's about it.  We
> already attach an auto-save itimer, so I tried running the benchmarks
> with that itimer deleted.  No change in running time. :-(

Wouldn't display-time-function be the appropriate shifty looking
person to put in the dock?  Looking at it, I see a call to
force-mode-line-update and a (sit-for 0) at the end.  Maybe the
culprit really is sit-for and display-time runs it frequently enough
for the problem to show easily.  

Hmm, didn't you say that you didn't see it until running the
benchmarks?  I assume you don't use display-time, so it may not be the
culprit.  The benchmarks have enough things in there that invoke
sit-for and input-pending-p.

Mysteries, mysteries,
-Sudish

