From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: Display slowness that is painful Date: Thu, 02 Feb 2006 12:33:26 +0100 Message-ID: References: <87slr5c78p.fsf@stupidchicken.com> <877j8fx43q.fsf@stupidchicken.com> <87mzhaqp7p.fsf@stupidchicken.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1138903600 29960 80.91.229.2 (2 Feb 2006 18:06:40 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 2 Feb 2006 18:06:40 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 02 19:06:38 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1F4iqn-00024v-Rd for ged-emacs-devel@m.gmane.org; Thu, 02 Feb 2006 19:06:34 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F4itv-0001Kq-HK for ged-emacs-devel@m.gmane.org; Thu, 02 Feb 2006 13:09:47 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1F4fTC-0002XW-Nr for emacs-devel@gnu.org; Thu, 02 Feb 2006 09:29:59 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1F4fIP-0007D8-Fs for emacs-devel@gnu.org; Thu, 02 Feb 2006 09:18:51 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F4f5b-0004TS-VH for emacs-devel@gnu.org; Thu, 02 Feb 2006 09:05:36 -0500 Original-Received: from [199.232.41.67] (helo=mx20.gnu.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1F4ew1-00075a-3F; Thu, 02 Feb 2006 08:55:41 -0500 Original-Received: from [195.41.46.235] (helo=pfepa.post.tele.dk) by mx20.gnu.org with esmtp (Exim 4.52) id 1F4cjM-0003xj-9K; Thu, 02 Feb 2006 06:34:28 -0500 Original-Received: from kfs-l.imdomain.dk.cua.dk (unknown [80.165.4.124]) by pfepa.post.tele.dk (Postfix) with SMTP id 9FA5F47FE81; Thu, 2 Feb 2006 12:34:22 +0100 (CET) Original-To: Chong Yidong In-Reply-To: <87mzhaqp7p.fsf@stupidchicken.com> (Chong Yidong's message of "Thu, 02 Feb 2006 00:55:38 -0500") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:49928 Archived-At: Chong Yidong writes: > "Richard M. Stallman" writes: > >> This is *really* not the time to make changes in redisplay. >> >> Yes it is. Even if we had started the pretest already, >> we would fix this bug. Or what are pretests for? I don't know -- it's been so long since I participated in one that I have forgot :-) > Managers of successful software projects often make the conscious > choice to postphone resolving bugs whose "fixes" can introduce even > more serious bugs while conferring limited benefits. (And they seem > to be able to actually make releases...) Yes, that is what "management" is all about -- making decisions when "enough is enough". > In this particular case, having looked through the relevant redisplay > code, I don't see any apparent code stupidity going on. It's simply > the case that, in this file, the first "newline" takes place 340,000 > characters in. Good catch!! That can definitely cause problems for redisplay as it does search for line beginnings/ends quite a lot, but usually the penalty is neglible. > The normally negligible delay from displaying glyphs > in octal format (v.s. unibyte-display-via-language-environment) is > magnified by this amount. The redisplay engine has to scroll through > the entire "line" to check for overlays, text properties, etc., and > this seems to be unavoidable. I tried to create two files like this: emacs -q C-x C-f file1.txt RET RET C-p ESC 3 4 0 0 0 0 x C-x C-f file2.txt RET RET C-p ESC 3 4 0 0 0 0 C-q 2 1 2 RET and indeed doing C-p C-n (or C-a C-e) in the second buffer is significantly slower than in the first buffer. Ok, one might expect it to be 4 times slower, but it is (feels) much slower than that (perhaps 8 times slower). It seems to be because it needs to merge_face with the escape glyph for each character -- and that takes extra time. Below is a patch to speed up the processing for this specific part of the problem. With the patch, redisplay time for file2 seems to be approx 4 x redisplay time for file1. *** xdisp.c 24 Jan 2006 09:30:15 +0100 1.1073 --- xdisp.c 02 Feb 2006 11:33:04 +0100 *************** *** 5329,5334 **** --- 5329,5338 ---- display element from the current position of IT. Value is zero if end of buffer (or C string) is reached. */ + static struct frame *last_escape_glyph_frame = NULL; + static unsigned last_escape_glyph_face_id = (1 << FACE_ID_BITS); + static int last_escape_glyph_merged_face_id = 0; + int get_next_display_element (it) struct it *it; *************** *** 5445,5455 **** --- 5449,5467 ---- face_id = merge_faces (it->f, Qt, lface_id, it->face_id); } + else if (it->f == last_escape_glyph_frame + && it->face_id == last_escape_glyph_face_id) + { + face_id = last_escape_glyph_merged_face_id; + } else { /* Merge the escape-glyph face into the current face. */ face_id = merge_faces (it->f, Qescape_glyph, 0, it->face_id); + last_escape_glyph_frame = it->f; + last_escape_glyph_face_id = it->face_id; + last_escape_glyph_merged_face_id = face_id; } XSETINT (it->ctl_chars[0], g); *************** *** 5496,5506 **** --- 5508,5526 ---- face_id = merge_faces (it->f, Qt, lface_id, it->face_id); } + else if (it->f == last_escape_glyph_frame + && it->face_id == last_escape_glyph_face_id) + { + face_id = last_escape_glyph_merged_face_id; + } else { /* Merge the escape-glyph face into the current face. */ face_id = merge_faces (it->f, Qescape_glyph, 0, it->face_id); + last_escape_glyph_frame = it->f; + last_escape_glyph_face_id = it->face_id; + last_escape_glyph_merged_face_id = face_id; } /* Handle soft hyphens in the mode where they only get *************** *** 10545,10550 **** --- 10565,10572 ---- retry: pause = 0; reconsider_clip_changes (w, current_buffer); + last_escape_glyph_frame = NULL; + last_escape_glyph_face_id = (1 << FACE_ID_BITS); /* If new fonts have been loaded that make a glyph matrix adjustment necessary, do it. */ -- Kim F. Storm http://www.cua.dk