From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Inefficient redisplay Date: Tue, 13 Apr 2010 23:05:02 +0300 Message-ID: <83hbnfxgnl.fsf@gnu.org> References: <83y6gsy4i0.fsf@gnu.org> <83pr24xuio.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1271189114 30617 80.91.229.12 (13 Apr 2010 20:05:14 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 13 Apr 2010 20:05:14 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 13 22:05:11 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1O1mM8-0004qK-7K for ged-emacs-devel@m.gmane.org; Tue, 13 Apr 2010 22:05:08 +0200 Original-Received: from localhost ([127.0.0.1]:34056 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O1mM7-0002Yp-Fs for ged-emacs-devel@m.gmane.org; Tue, 13 Apr 2010 16:05:07 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O1mM2-0002Ya-31 for emacs-devel@gnu.org; Tue, 13 Apr 2010 16:05:02 -0400 Original-Received: from [140.186.70.92] (port=39474 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O1mLz-0002YS-6k for emacs-devel@gnu.org; Tue, 13 Apr 2010 16:05:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O1mLx-0004qZ-3r for emacs-devel@gnu.org; Tue, 13 Apr 2010 16:04:58 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:55877) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O1mLw-0004qT-RZ for emacs-devel@gnu.org; Tue, 13 Apr 2010 16:04:57 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0L0T00300ZIRSJ00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Tue, 13 Apr 2010 23:04:55 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([77.127.74.198]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0L0T00IHFZS6QDJ0@a-mtaout22.012.net.il>; Tue, 13 Apr 2010 23:04:55 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) 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:123597 Archived-At: > From: Stefan Monnier > Cc: emacs-devel@gnu.org > Date: Mon, 12 Apr 2010 17:46:21 -0400 > > > Also, what _is_ the problem, exactly? Is that only that jit-lock > > misbehaves, or is there something else? You said in your original > > mail that "redisplay code somehow seems to treat nhexl-mode's buffers > > as one single long-line", but what are the symptoms of this? > > Several problems: > 1- it seems that I'm not able to have position N displayed without > having all positions 1..N with fontified set to non-nil (I.e. I have > to have all the prefix of the buffer fontified). That's a major > problem since I use overlays: if N is large, that implies a large > number of overlays, which implies serious performance problems. > 2- performance sucks. Maybe it's because of 1, but it's probably not > only due to that, because performance is better when I go back to the > beginning of the buffer (which doesn't remove overlays). I'm not sure I see the root cause yet, or even the most expensive part, but one thing seems to be quite clear: the way you move overlays disables quite a few of redisplay optimizations. For example, if I just move cursor, in a normal buffer redisplay calls try_cursor_movement, and that's it. But in a buffer under nhexl-mode, try_cursor_movement is not even called because of this condition: current_matrix_up_to_date_p = (!NILP (w->window_end_valid) && !current_buffer->clip_changed && !current_buffer->prevent_redisplay_optimizations_p && XFASTINT (w->last_modified) >= MODIFF && XFASTINT (w->last_overlay_modified) >= OVERLAY_MODIFF); It seems like the games you play in post-command-hook constantly increment OVERLAY_MODIFF, and that prevents this optimization. Instead, redisplay invokes try_window_id, which promptly gives up here: if (current_buffer->clip_changed || current_buffer->prevent_redisplay_optimizations_p) GIVE_UP (3); because someone turned on the prevent_redisplay_optimizations_p flag (I don't yet know why). Then try_window is called, which is much heavier, and it does the job. This happens for every cursor movement! Why do you need to modify overlays in a post-command-hook? That seems to be at least part of the trouble.