From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#16526: 24.3.50; scroll-conservatively & c-mode regression Date: Sat, 25 Jan 2014 12:30:18 +0200 Message-ID: <838uu4cq11.fsf@gnu.org> References: <52E38286.1050306@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1390645878 7198 80.91.229.3 (25 Jan 2014 10:31:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 25 Jan 2014 10:31:18 +0000 (UTC) Cc: acm@muc.de, 16526@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jan 25 11:31:23 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 1W70WI-0004QK-36 for geb-bug-gnu-emacs@m.gmane.org; Sat, 25 Jan 2014 11:31:22 +0100 Original-Received: from localhost ([::1]:50603 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W70WH-0000Oa-N0 for geb-bug-gnu-emacs@m.gmane.org; Sat, 25 Jan 2014 05:31:21 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50068) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W70W9-0000OU-Nk for bug-gnu-emacs@gnu.org; Sat, 25 Jan 2014 05:31:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W70W4-0005b0-MZ for bug-gnu-emacs@gnu.org; Sat, 25 Jan 2014 05:31:13 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:49325) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W70Vz-0005aJ-4u; Sat, 25 Jan 2014 05:31:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1W70Vy-00036k-Dq; Sat, 25 Jan 2014 05:31:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Sat, 25 Jan 2014 10:31: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.139064584011915 (code B ref 16526); Sat, 25 Jan 2014 10:31:02 +0000 Original-Received: (at 16526) by debbugs.gnu.org; 25 Jan 2014 10:30:40 +0000 Original-Received: from localhost ([127.0.0.1]:35111 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W70Vb-000366-CB for submit@debbugs.gnu.org; Sat, 25 Jan 2014 05:30:39 -0500 Original-Received: from mtaout26.012.net.il ([80.179.55.182]:35215) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W70VU-00035n-W2 for 16526@debbugs.gnu.org; Sat, 25 Jan 2014 05:30:35 -0500 Original-Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0MZY00C00D51HD00@mtaout26.012.net.il> for 16526@debbugs.gnu.org; Sat, 25 Jan 2014 12:29:49 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MZY005KMD5ODC70@mtaout26.012.net.il>; Sat, 25 Jan 2014 12:29:49 +0200 (IST) In-reply-to: <52E38286.1050306@gmx.at> X-012-Sender: halo1@inter.net.il 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:83976 Archived-At: > Date: Sat, 25 Jan 2014 10:23:18 +0100 > From: martin rudalics > Cc: Alan Mackenzie > > >> With current trunk and emacs -Q evaluating the following form takes more > >> than two minutes here with builds on Windows and GNU/Linux: > > > >> (progn > >> (setq scroll-conservatively 101) > >> (find-file (concat source-directory "src/xdisp.c")) > >> (end-of-buffer) > >> (sit-for 3) > >> (beginning-of-buffer)) > > > >> It used to take about 10 seconds before revision 116070. > > > > It's taking me about 7 seconds, on an Emacs version whose latest applied > > revision is 116070. > > > > Quick update to current (latest revision 116146), and rebuild ....... > > > > It's still taking me about 7 seconds. > > Updated to revision 116153, bootstrapped (at least one hour on my > machine), still taking more than two minutes here. I see this too, both on Windows and on GNU/Linux. Here's the profile: - redisplay_internal (C function) 2560 95% - jit-lock-function 2560 95% - jit-lock-fontify-now 2560 95% - funcall 2560 95% - # 2560 95% - run-hook-with-args 2560 95% - font-lock-fontify-region 2560 95% - c-font-lock-fontify-region 2560 95% - font-lock-default-fontify-region 2559 95% - font-lock-fontify-keywords-region 2547 94% - c-font-lock-complex-decl-prepare 2543 94% - c-parse-state 2543 94% - c-parse-state-1 2543 94% - c-append-lower-brace-pair-to-state-cache 2542 94% byte-code 2542 94% - c-append-to-state-cache 1 0% byte-code 1 0% + # 3 0% + c-font-lock-enum-tail 1 0% + font-lock-fontify-syntactically-region 12 0% + mapc 1 0% + command-execute 116 4% + ... 6 0% This takes about 40 seconds on a fast (Core i7) machine. > > As far as I can see, you haven't > > installed your temporary patch to syntax.c. > > I'm afraid I have to do that now. > > > So, I haven't been able to > > reproduce the problem yet. > > > > Is there something more subtle I'm missing? > > Is there something more subtle I'm missing? Probably. I actually don't understand how come scroll-conservatively affects non-scrolling commands. Can you elaborate on that? You also mentioned back_comment doing something unreasonable. Can you expand on that, too? This part specifically I don't understand: > What happens is that apparently back_comment 530 times scans the buffer > from the beginning of the buffer to the first comment before the current > position where the list of current positions goes like this: Since the problem happens as result of beginning-of-buffer, why would back_comment need to "scan the buffer from the beginning of the buffer to the first comment before the current position"? And what is the current position in this case? Btw, if I disable font-lock ("M-x global-font-lock-mode RET") before repeating the recipe, the move to bob is instantaneous, and turning on font-lock after that doesn't seem to have any adverse effects on responsiveness.