From xemacs-m  Wed Mar 26 13:37:00 1997
Received: from mailbox1.ucsd.edu (mailbox1.ucsd.edu [132.239.1.53])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id NAA03710
	for <xemacs-beta@xemacs.org>; Wed, 26 Mar 1997 13:36:59 -0600 (CST)
Received: from sdnp5.ucsd.edu (sdnp5.ucsd.edu [132.239.79.10]) by mailbox1.ucsd.edu (8.8.5/8.6.9) with SMTP id LAA29792 for <xemacs-beta@xemacs.org>; Wed, 26 Mar 1997 11:37:00 -0800 (PST)
Received: by sdnp5.ucsd.edu (SMI-8.6/SMI-SVR4)
	id LAA19189; Wed, 26 Mar 1997 11:38:49 -0800
Sender: dmoore@sdnp5.ucsd.edu
To: xemacs-beta@xemacs.org
Subject: Re: 20.1b9 still very slow
References: <199703261901.LAA24907@sandman>
X-Face: "oX;zS#-JU$-,WKSzG.1gGE]x^cIg!hW.dq>.f6pzS^A+(k!T|M:}5{_%>Io<>L&{hO7W4cicOQ|>/lZ1G(m%7iaCf,6Qgk0%%Bz7b2-W3jd0m_UG\Y;?]}4s0O-U)uox>P3JN)9cm]O\@,vy2e{`3pb!"pqmRy3peB90*2L
Mail-Copies-To: never
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=US-ASCII
From: David Moore <dmoore@ucsd.edu>
Date: 26 Mar 1997 11:38:48 -0800
In-Reply-To: Dan Rich's message of Wed, 26 Mar 1997 11:01:42 -0800
Message-ID: <rvafnqmojb.fsf@sdnp5.ucsd.edu>
Lines: 60
X-Mailer: Gnus v5.4.37/XEmacs 19.15

Dan Rich <drich@cisco.com> writes:

> Am I the only one seeing performance problems in the latest 20.1
> betas?  I timed it yesterday, and on my system it took over 15 seconds 
> for XEmacs to display a line of text that I typed in an outgoing
> e-mail buffer (in VM 6.22).  This is built on an UntraSparc 140 with
> gcc 2.7.2 and X11R6.3.

Hmm, something sounds broken. :) Although, since you are using vm
(mailer of the gods!), what might be happening is that a timer went off
to update the cache in your various vm files.  Although, I think it's
supposed to stop updating it if it notices you typing.


> Running a truss doesn't show anything too interesting, except that it
> is making hundreds of calls to getcontext().  Is this normal?  Just
> moving the pointer in and back out of the XEmacs window just caused
> 417 calls to getcontext in an idle XEmacs process!

Righto.  Solaris has a threaded X client library.  So you'll see lots of
calls to getcontext around select/poll or read/write which is typically
related to the x code doing something.  So I'd just ignore those from
truss.

Two other things you can do:

1) C level:

When you see it going mad like this, you might want to use gdb from an
*xterm* to attach to the running process and get a stack trace.  To do
this just run:

gdb /path/to/xemacs/xemacs ####

Where #### is the process id of your xemacs, instead of specifying the
core.  When gdb attaches, the xemacs will stop [1] and you can type
`where' in gdb to get a stack trace as usual.  To get things moving
again, you can just type `quit' in gdb.  It'll tell you the program is
running and ask if you want to quit anyways.  Say 'y' and it'll quit and
have your emacs continue from where it was at.


2) Lisp level:

Turn on debug-on-quit early on.  When you think things are going slow
hit C-g and it may pop you in the debugger so you can see what routine
is running.  Press `c' to get going again.

debug-on-quit doesn't work if something's turned on inhibit-quit or in
some other strange cases.


Beta FAQ people:  Maybe there is a good place to put suggestions like
this on how to find out where XEmacs is wedging?

-- 
David Moore <dmoore@ucsd.edu>       | Computer Systems Lab      __o
UCSD Dept. Computer Science - 0114  | Work: (619) 534-8604    _ \<,_
La Jolla, CA 92093-0114             | Fax:  (619) 534-1445   (_)/ (_)
<URL:http://oj.egbt.org/dmoore/>    | In a cloud bones of steel.

