From xemacs-m  Thu Dec  5 20:49:01 1996
Received: from norway.aosi.com (mail.aosi.com [206.98.255.23]) by xemacs.cs.uiuc.edu (8.8.3/8.8.3) with ESMTP id UAA08247 for <xemacs-beta@xemacs.org>; Thu, 5 Dec 1996 20:49:01 -0600 (CST)
Received: from hlork ([206.98.254.45]) by norway.aosi.com
          (post.office MTA v2.0 0813 ID# 0-16356) with SMTP id AAA116
          for <xemacs-beta@xemacs.org>; Thu, 5 Dec 1996 21:50:31 -0500
Sender: joel
Message-ID: <32A78BF5.18300EE4@aosi.com>
Date: Thu, 05 Dec 1996 21:59:01 -0500
From: Joel Peterson <tarzan@aosi.com>
Organization: Me Tarzan, you Jane?
X-Mailer: Mozilla 3.0 (X11; U; Linux 2.0.25 i586)
MIME-Version: 1.0
To: xemacs-beta@xemacs.org
Subject: XEmacs redisplay optimization work and unrelated buffer stuff (2nd try)
References: <199612041913.NAA29309@xemacs.cs.uiuc.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Apparently, my first try to send this got eaten by the new mailing list
software.  Here it is again:

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.

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).

--
"The Secret to Procastination is...
 I'll finish this later.  I wonder what's on TV?"
                - Joel Peterson
                       Supreme Deputy of scratching Dogbert behind the
                       ears until he has little leg spasms.

