From xemacs-m  Fri Dec  6 02:58:19 1996
Received: from venus.Sun.COM (venus.Sun.COM [192.9.25.5]) by xemacs.cs.uiuc.edu (8.8.3/8.8.3) with SMTP id CAA09445 for <xemacs-beta@xemacs.org>; Fri, 6 Dec 1996 02:58:19 -0600 (CST)
Received: from Eng.Sun.COM ([129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id AAA22946; Fri, 6 Dec 1996 00:57:49 -0800
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id AAA23864; Fri, 6 Dec 1996 00:57:48 -0800
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id AAA22816; Fri, 6 Dec 1996 00:57:47 -0800
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id AAA03840; Fri, 6 Dec 1996 00:57:45 -0800
Date: Fri, 6 Dec 1996 00:57:45 -0800
Message-Id: <199612060857.AAA03840@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@Eng.Sun.COM>
To: Joel Peterson <tarzan@aosi.com>
Cc: XEmacs Beta Test <xemacs-beta@xemacs.org>
Subject: XEmacs redisplay optimization work and unrelated buffer stuff (2nd try)
In-Reply-To: <32A78BF5.18300EE4@aosi.com>
References: <199612041913.NAA29309@xemacs.cs.uiuc.edu>
	<32A78BF5.18300EE4@aosi.com>
Reply-To: Martin Buchholz <mrb@Eng.Sun.COM>
Mime-Version: 1.0 (generated by tm-edit 7.94)
Content-Type: text/plain; charset=US-ASCII

>>>>> "Joel" == Joel Peterson <tarzan@aosi.com> writes:

Joel> Is work progressing on any redisplay optimizations or is it on
Joel> hold right now?  Is there anything I can do to help
Joel> (specifically with X or generic redisplay issues)?  I'll have
Joel> some time coming up to putter around with this stuff and I'm
Joel> looking for some direction.

It would be great if someone could look at the performance issues.

Stability has improved a lot, although there are still a few
outstanding unsolved crashes (but I only know of one I can reproduce!)

What are the reasons to use GNU Emacs instead of XEmacs?

- display performance
- tty performance
- runs on Windoze
- Mule functionality is available with Mule 2.3 and has been working
  for a long time.  XEmacs 20.0 Mule is still young.  I personally
  will continue to work on this for a while.  Even this is too big a
  job for one person and I will need help.

If we can fix these problems, Emacs will be used only by the
GUI-averse, a sizeable but shrinking set of users.

As Chuck has pointed out, we can never expect performance of XEmacs to
equal performance of GNU Emacs, since there is a price to be paid for
the display features.  Nevertheless, there is definitely scope for
optimization. 

The price for Mule support is pretty heavy too - on the order of 30%.

Joel, you can be a hero if you can make a sizeable impact on the
performance problems.  Finding the performance hot spots is generally
the first step.  This is currently not known. (Chuck explained in a
previous article why tty support is slow).

Joel> As a side issue; is there anything that can be done to improve the speed
Joel> of random inserts and deletes into a large buffer that won't break
Joel> everything in emacs?  Right now, I have a worst case scenario for
Joel> inserts and deletes with a process filter inserting new lines at the top
Joel> of a ~1MB buffer; while at the same time deleting a line from the bottom
Joel> of the buffer if the maximum number of lines has been exceeded
Joel> (arbitrary inserts/deletes are also possible but less common).  As soon
Joel> as the maximum number of lines is reached; the amount of time spent in
Joel> insert as reported by pretty-print-profiling-info jumps from miniscule
Joel> to a level rivaling `(in redisplay)'.

Joel> I've optimized the insert at top/delete from bottom a little by putting
Joel> a function onto the pre-idle-hook that deletes lines en-masse from the
Joel> bottom, allowing some localization.  However, with new lines coming in
Joel> at a rate of several per second; and with several process windows open,
Joel> things can get quite slow.

Joel> For the specific case of buffer trimming, it could be made much faster
Joel> if delete-region could be told not to memmove the gap down and then back
Joel> up the entire buffer, especially for deletes from the bottom.  Is there
Joel> a compelling reason to ever have a delete from x to (point-max) actually
Joel> move the gap?  (other than that it would have to be special cased and
Joel> would probably only ever help me).

I think deleting to (point-max) is very common.  Special casing that
may very well be worth doing.

-- 
Martin Buchholz <mrb@eng.sun.com>
XEmacs Developer, Sun Microsystems Inc.

