From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#16526: 24.3.50; scroll-conservatively & c-mode regression Date: Sun, 2 Feb 2014 17:40:50 +0000 Message-ID: <20140202174050.GA5365__39445.5885202207$1391367777$gmane$org@acm.acm> References: <52E4EF61.3050404@gmx.at> <831tzubqxw.fsf@gnu.org> <20140126204310.GA3937@acm.acm> <52E61704.6050807@gmx.at> <20140129223626.GD3092@acm.acm> <52EA0124.4000809@gmx.at> <52EA57D6.5080403@gmx.at> <83txcl75nj.fsf@gnu.org> <52EAA0C9.1090000@gmx.at> <834n4j5d3k.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1391367764 4204 80.91.229.3 (2 Feb 2014 19:02:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 2 Feb 2014 19:02:44 +0000 (UTC) Cc: 16526@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Feb 02 20:02:48 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WA2Jb-0005AT-JJ for geb-bug-gnu-emacs@m.gmane.org; Sun, 02 Feb 2014 20:02:47 +0100 Original-Received: from localhost ([::1]:42396 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WA2Jb-0005ys-83 for geb-bug-gnu-emacs@m.gmane.org; Sun, 02 Feb 2014 14:02:47 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60993) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WA2Ih-0004w8-8Z for bug-gnu-emacs@gnu.org; Sun, 02 Feb 2014 14:01:55 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WA2Ic-0004Ze-HE for bug-gnu-emacs@gnu.org; Sun, 02 Feb 2014 14:01:51 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:60785) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WA16N-0002F4-Ek; Sun, 02 Feb 2014 12:45:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WA16M-00012w-Le; Sun, 02 Feb 2014 12:45:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Sun, 02 Feb 2014 17:45:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16526 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: Original-Received: via spool by 16526-submit@debbugs.gnu.org id=B16526.13913630533946 (code B ref 16526); Sun, 02 Feb 2014 17:45:02 +0000 Original-Received: (at 16526) by debbugs.gnu.org; 2 Feb 2014 17:44:13 +0000 Original-Received: from localhost ([127.0.0.1]:46571 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WA15Y-00011Z-Lm for submit@debbugs.gnu.org; Sun, 02 Feb 2014 12:44:13 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:26646 helo=mail.muc.de) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WA15V-00011O-Bz for 16526@debbugs.gnu.org; Sun, 02 Feb 2014 12:44:10 -0500 Original-Received: (qmail 42563 invoked by uid 3782); 2 Feb 2014 17:44:07 -0000 Original-Received: from acm.muc.de (p5492C63E.dip0.t-ipconnect.de [84.146.198.62]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 02 Feb 2014 18:44:06 +0100 Original-Received: (qmail 5850 invoked by uid 1000); 2 Feb 2014 17:40:51 -0000 Content-Disposition: inline In-Reply-To: <834n4j5d3k.fsf@gnu.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:84457 Archived-At: Hello, Eli. On Sat, Feb 01, 2014 at 12:41:51PM +0200, Eli Zaretskii wrote: > > Date: Thu, 30 Jan 2014 19:58:17 +0100 > > From: martin rudalics > > CC: acm@muc.de, 16526@debbugs.gnu.org > > > It takes about 11 sec here. But reverting the patch doesn't change > > > this timing, I still get 11 sec. > > But it does take longer with a maximized window? > Yes, it does. > > If so, do you have an explanation? > Those 11 seconds are spent inside 'recenter', which is called by > end-of-buffer: > ;; If we went to a place in the middle of the buffer, > ;; adjust it to the beginning of a line. > (cond ((and arg (not (consp arg))) (forward-line 1)) > ((and (eq (current-buffer) (window-buffer)) > (> (point) (window-end nil t))) > ;; If the end of the buffer is not already on the screen, > ;; then scroll specially to put it near, but not at, the bottom. > (overlay-recenter (point)) > (recenter -3)))) <<<<<<<<<<<<<<<<<<<<<<<<<< > Stepping through 'recenter', I see the following: > . It treats GUI frames specially (and indeed, in "emacs -nw", I > don't see this slowdown). The special handling is that it > attempts to find the window-start point that corresponds to the -3 > argument, by interpreting that argument as the number of pixels > equivalent to 3 canonical-height lines. > . To this end, 'recenter' calls move_it_vertically_backward with the > -3 argument converted to pixels. move_it_vertically_backward then > tries to find that place, by simulating display. > . As part of the display simulation, jit-lock-function is called > (because we hit a buffer position which has a non-nil 'fontified' > property) with a single argument: buffer position 948757. This > single call takes almost all of the 11 seconds. > When the frame is not maximized, the window height is smaller, so > 'recenter' moves back a smaller amount of pixels, and calls > jit-lock-function at a different buffer position. That call takes > only about 2 sec (still quite a lot, IMO). > Perhaps Alan could explain why the CC Mode fontification takes such a > long time for buffer position 948757. No, sorry I can't explain it. Except that CC Mode will be scanning forward through the entire buffer once (hopefully only once) to get the "parse state" near EOB. On a normally optimised 24.3 build, M-x goto-char 948757 is taking me a little over a second. This is in a GUI frame in X Windows, maximised by clicking on the maximise button at the top right of the frame. On my non-optimised 24.3.50 build with tracing built in, the same action, M-x goto-char 948757 takes 9 seconds. In a non-maximised frame it takes 8 seconds. In this build, M-> takes ~2 seconds regardless of whether the frame is maximised or not. I can't explain this difference. I've committed my patch. I hope it clears up the bug (which I haven't yet closed) more or less satisfactorally. -- Alan Mackenzie (Nuremberg, Germany).