From xemacs-m  Mon Dec  9 20:16:14 1996
Received: from proxy1.ba.best.com (root@proxy1.ba.best.com [206.184.139.12]) by xemacs.cs.uiuc.edu (8.8.3/8.8.3) with ESMTP id UAA21401 for <xemacs-beta@xemacs.org>; Mon, 9 Dec 1996 20:16:13 -0600 (CST)
Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by proxy1.ba.best.com (8.8.4/8.8.3) with ESMTP id SAA04972 for <xemacs-beta@xemacs.org>; Mon, 9 Dec 1996 18:12:13 -0800 (PST)
Received: from 666.com (shellx.best.com [206.86.0.11]) by shellx.best.com (8.8.4/8.8.3) with SMTP id SAA15202 for <xemacs-beta@xemacs.org>; Mon, 9 Dec 1996 18:10:47 -0800 (PST)
Date: Mon, 9 Dec 1996 18:10:47 -0800 (PST)
Message-Id: <199612100210.SAA15202@shellx.best.com>
From: Ben Wing <ben@666.com>
To: Joel Peterson <tarzan@aosi.com>, xemacs-beta@xemacs.org
Subject: Re:  XEmacs redisplay optimization work and unrelated buffer stuff

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

You would have to ask Chuck but I imagine that nothing is going to get
done here for awhile (unless you do it of course :).  Highest priority
is TTY optimization I think.

>
>As a side issue; is there anything that can be done to improve the speed
>of random inserts and deletes into a large buffer that won't break
>everything in emacs?  Right now, I have a worst case scenario for
>inserts and deletes with a process filter inserting new lines at the top
>of a ~1MB buffer; while at the same time deleting a line from the bottom
>of the buffer if the maximum number of lines has been exceeded
>(arbitrary inserts/deletes are also possible but less common).  As soon
>as the maximum number of lines is reached; the amount of time spent in
>insert as reported by pretty-print-profiling-info jumps from miniscule
>to a level rivaling `(in redisplay)'.
>
>I've optimized the insert at top/delete from bottom a little by putting
>a function onto the pre-idle-hook that deletes lines en-masse from the
>bottom, allowing some localization.  However, with new lines coming in
>at a rate of several per second; and with several process windows open,
>things can get quite slow.
>
>For the specific case of buffer trimming, it could be made much faster
>if delete-region could be told not to memmove the gap down and then back
>up the entire buffer, especially for deletes from the bottom.  Is there
>a compelling reason to ever have a delete from x to (point-max) actually
>move the gap?  (other than that it would have to be special cased and
>would probably only ever help me).

I have cleaned up this code immensely, so it just may be possible to
fix things so that deletions don't require moving the gap.  The only
tricky thing is making sure that markers and extents are handled
correctly.  Implementing multiple gaps, on the other hand, will still
be quite difficult and apparently not necessary for your purposes.

ben
--
(This message composed by voice)
[and a major pain in the ass at that]

