* bug#10652: 24.0.93; font-lock very slow for C++
@ 2012-01-30 11:15 Helmut Eller
2012-02-26 9:47 ` Chong Yidong
` (3 more replies)
0 siblings, 4 replies; 14+ messages in thread
From: Helmut Eller @ 2012-01-30 11:15 UTC (permalink / raw)
To: 10652
Font lock is extremely slow in this file:
http://hg.openjdk.java.net/jdk7/jdk7/hotspot/raw-file/b92c45f2bc75/src/share/vm/runtime/globals.hpp
Download the file and open it with emacs -Q globals.hpp. Then
scroll around in the file to see how slow it is.
^ permalink raw reply [flat|nested] 14+ messages in thread* bug#10652: 24.0.93; font-lock very slow for C++ 2012-01-30 11:15 bug#10652: 24.0.93; font-lock very slow for C++ Helmut Eller @ 2012-02-26 9:47 ` Chong Yidong 2012-03-01 19:36 ` Alan Mackenzie ` (2 more replies) 2012-03-14 9:45 ` bug#10652: " Toon Claes ` (2 subsequent siblings) 3 siblings, 3 replies; 14+ messages in thread From: Chong Yidong @ 2012-02-26 9:47 UTC (permalink / raw) To: Alan Mackenzie; +Cc: Helmut Eller, 10652 Helmut Eller <eller.helmut@gmail.com> writes: > Font lock is extremely slow in this file: > > http://hg.openjdk.java.net/jdk7/jdk7/hotspot/raw-file/b92c45f2bc75/src/share/vm/runtime/globals.hpp > > Download the file and open it with emacs -Q globals.hpp. Then > scroll around in the file to see how slow it is. I got Emacs into an uninterruptible loop while scrolling through the buffer :-( Looks like a regression against Emacs 23's CC mode, which handles the file just fine. Alan, could you investigate? Thanks. ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#10652: 24.0.93; font-lock very slow for C++ 2012-02-26 9:47 ` Chong Yidong @ 2012-03-01 19:36 ` Alan Mackenzie 2012-03-02 22:27 ` Alan Mackenzie 2012-03-16 14:19 ` Alan Mackenzie 2 siblings, 0 replies; 14+ messages in thread From: Alan Mackenzie @ 2012-03-01 19:36 UTC (permalink / raw) To: Chong Yidong; +Cc: Helmut Eller, 10652 Hello Yidong, hello Helmut. On Sun, Feb 26, 2012 at 05:47:25PM +0800, Chong Yidong wrote: > Helmut Eller <eller.helmut@gmail.com> writes: > > Font lock is extremely slow in this file: > > http://hg.openjdk.java.net/jdk7/jdk7/hotspot/raw-file/b92c45f2bc75/src/share/vm/runtime/globals.hpp > > Download the file and open it with emacs -Q globals.hpp. Then > > scroll around in the file to see how slow it is. > I got Emacs into an uninterruptible loop while scrolling through the > buffer :-( > Looks like a regression against Emacs 23's CC mode, which handles the > file just fine. Alan, could you investigate? Thanks. OK. First point: this is the first time I've ever seen a file with a 3350 line macro. ;-) There are several places in CC Mode which assume macros are small, so it's not too surprising that this file goes slowly. I've elp'd the scrolling, and have the following fix as a first approximation. Please try it out, but it's not fully tested, so don't use it in anger. Just one thing: if you've already got CC Mode running when you load in this version, please do (setq-default c-macro-names-with-semicolon nil) before M-x c++-mode, to clear out a stale value. There are more optimisations I'm looking at at the moment. Here's the patch: diff -r 915250820ea6 cc-engine.el --- a/cc-engine.el Wed Feb 29 18:59:34 2012 +0000 +++ b/cc-engine.el Thu Mar 01 19:23:24 2012 +0000 @@ -222,6 +222,38 @@ (point)))) c-macro-start)) +;; One element macro cache to cope with continual movement within very large +;; CPP macros. +(defvar c-macro-cache nil) +(make-variable-buffer-local 'c-macro-cache) +;; Nil or cons of the bounds of the most recent CPP form probed by +;; `c-beginning-of-macro', `c-end-of-macro' or `c-syntactic-end-of-macro'. +;; The cdr will be nil if we know only the start of the CPP form. +(defvar c-macro-cache-start-pos nil) +(make-variable-buffer-local 'c-macro-cache-start-pos) +;; The starting position from where we determined `c-macro-cache'. +(defvar c-macro-cache-syntactic nil) +(make-variable-buffer-local 'c-macro-cache-syntactic) +;; non-nil iff `c-macro-cache' has both elements set AND the cdr is at a +;; syntactic end of macro, not merely an apparent one. + +(defun c-invalidate-macro-cache (beg end) + ;; Called from a before-change function. If the change region is before or + ;; in the macro characterised by `c-macro-cache' etc., nullify it + ;; appropriately. BEG and END are the standard before-change-functions + ;; parameters. END isn't used. + (cond + ((null c-macro-cache)) + ((< beg (car c-macro-cache)) + (setq c-macro-cache nil + c-macro-cache-start-pos nil + c-macro-cache-syntactic nil)) + ((and (cdr c-macro-cache) + (< beg (cdr c-macro-cache))) + (setcdr c-macro-cache nil) + (setq c-macro-cache-start-pos beg + c-macro-cache-syntactic nil)))) + (defun c-beginning-of-macro (&optional lim) "Go to the beginning of a preprocessor directive. Leave point at the beginning of the directive and return t if in one, @@ -229,19 +261,36 @@ Note that this function might do hidden buffer changes. See the comment at the start of cc-engine.el for more info." - (when c-opt-cpp-prefix - (let ((here (point))) - (save-restriction - (if lim (narrow-to-region lim (point-max))) - (beginning-of-line) - (while (eq (char-before (1- (point))) ?\\) - (forward-line -1)) - (back-to-indentation) - (if (and (<= (point) here) - (looking-at c-opt-cpp-start)) - t - (goto-char here) - nil))))) + (let ((here (point))) + (when c-opt-cpp-prefix + (if (and (car c-macro-cache) + (>= (point) (car c-macro-cache)) + (or (and (cdr c-macro-cache) + (<= (point) (cdr c-macro-cache))) + (<= (point) c-macro-cache-start-pos))) + (unless (< (car c-macro-cache) (or lim (point-min))) + (progn (goto-char (max (or lim (point-min)) (car c-macro-cache))) + (setq c-macro-cache-start-pos + (max c-macro-cache-start-pos here)) + t)) + (setq c-macro-cache nil + c-macro-cache-start-pos nil + c-macro-cache-syntactic nil) + + (save-restriction + (if lim (narrow-to-region lim (point-max))) + (beginning-of-line) + (while (eq (char-before (1- (point))) ?\\) + (forward-line -1)) + (back-to-indentation) + (if (and (<= (point) here) + (looking-at c-opt-cpp-start)) + (progn + (setq c-macro-cache (cons (point) nil) + c-macro-cache-start-pos here) + t) + (goto-char here) + nil)))))) (defun c-end-of-macro () "Go to the end of a preprocessor directive. @@ -251,12 +300,24 @@ Note that this function might do hidden buffer changes. See the comment at the start of cc-engine.el for more info." - (while (progn - (end-of-line) - (when (and (eq (char-before) ?\\) - (not (eobp))) - (forward-char) - t)))) + (if (and (cdr c-macro-cache) + (<= (point) (cdr c-macro-cache)) + (>= (point) (car c-macro-cache))) + (goto-char (cdr c-macro-cache)) + (unless (and (car c-macro-cache) + (<= (point) c-macro-cache-start-pos) + (>= (point) (car c-macro-cache))) + (setq c-macro-cache nil + c-macro-cache-start-pos nil + c-macro-cache-syntactic nil)) + (while (progn + (end-of-line) + (when (and (eq (char-before) ?\\) + (not (eobp))) + (forward-char) + t))) + (when (car c-macro-cache) + (setcdr c-macro-cache (point))))) (defun c-syntactic-end-of-macro () ;; Go to the end of a CPP directive, or a "safe" pos just before. @@ -271,12 +332,15 @@ ;; at the start of cc-engine.el for more info. (let* ((here (point)) (there (progn (c-end-of-macro) (point))) - (s (parse-partial-sexp here there))) - (while (and (or (nth 3 s) ; in a string - (nth 4 s)) ; in a comment (maybe at end of line comment) - (> there here)) ; No infinite loops, please. - (setq there (1- (nth 8 s))) - (setq s (parse-partial-sexp here there))) + s) + (unless c-macro-cache-syntactic + (setq s (parse-partial-sexp here there)) + (while (and (or (nth 3 s) ; in a string + (nth 4 s)) ; in a comment (maybe at end of line comment) + (> there here)) ; No infinite loops, please. + (setq there (1- (nth 8 s))) + (setq s (parse-partial-sexp here there))) + (setq c-macro-cache-syntactic (car c-macro-cache))) (point))) (defun c-forward-over-cpp-define-id () diff -r 915250820ea6 cc-fonts.el --- a/cc-fonts.el Wed Feb 29 18:59:34 2012 +0000 +++ b/cc-fonts.el Thu Mar 01 19:23:24 2012 +0000 @@ -409,7 +409,8 @@ (cc-eval-when-compile (boundp 'parse-sexp-lookup-properties))) (BOD-limit - (c-determine-limit 1000))) + (c-determine-limit 500 ;; 1000 + ))) (goto-char (let ((here (point))) (if (eq (car (c-beginning-of-decl-1 BOD-limit)) 'same) diff -r 915250820ea6 cc-langs.el --- a/cc-langs.el Wed Feb 29 18:59:34 2012 +0000 +++ b/cc-langs.el Thu Mar 01 19:23:24 2012 +0000 @@ -444,8 +444,10 @@ ;; For documentation see the following c-lang-defvar of the same name. ;; The value here may be a list of functions or a single function. t nil - c++ '(c-extend-region-for-CPP c-before-change-check-<>-operators) - (c objc) 'c-extend-region-for-CPP + c++ '(c-extend-region-for-CPP + c-before-change-check-<>-operators + c-invalidate-macro-cache) + (c objc) '(c-extend-region-for-CPP c-invalidate-macro-cache) ;; java 'c-before-change-check-<>-operators awk 'c-awk-record-region-clear-NL) (c-lang-defvar c-get-state-before-change-functions diff -r 915250820ea6 cc-vars.el --- a/cc-vars.el Wed Feb 29 18:59:34 2012 +0000 +++ b/cc-vars.el Thu Mar 01 19:23:24 2012 +0000 @@ -1653,7 +1653,8 @@ c-macro-names-with-semicolon)))))) (defvar c-macro-names-with-semicolon - '("Q_OBJECT" "Q_PROPERTY" "Q_DECLARE" "Q_ENUMS") +; '("Q_OBJECT" "Q_PROPERTY" "Q_DECLARE" "Q_ENUMS") + nil "List of #defined symbols whose expansion ends with a semicolon. Alternatively it can be a string, a regular expression which matches all such symbols. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#10652: 24.0.93; font-lock very slow for C++ 2012-02-26 9:47 ` Chong Yidong 2012-03-01 19:36 ` Alan Mackenzie @ 2012-03-02 22:27 ` Alan Mackenzie 2012-03-16 14:19 ` Alan Mackenzie 2 siblings, 0 replies; 14+ messages in thread From: Alan Mackenzie @ 2012-03-02 22:27 UTC (permalink / raw) To: Chong Yidong; +Cc: Helmut Eller, 10652 Hello Yidong, hello Helmut. On Sun, Feb 26, 2012 at 05:47:25PM +0800, Chong Yidong wrote: > Helmut Eller <eller.helmut@gmail.com> writes: > > Font lock is extremely slow in this file: > > http://hg.openjdk.java.net/jdk7/jdk7/hotspot/raw-file/b92c45f2bc75/src/share/vm/runtime/globals.hpp > > Download the file and open it with emacs -Q globals.hpp. Then > > scroll around in the file to see how slow it is. > I got Emacs into an uninterruptible loop while scrolling through the > buffer :-( > Looks like a regression against Emacs 23's CC mode, which handles the > file just fine. Alan, could you investigate? Thanks. I've just committed a collection of optimisations as revision #107485. I can now scroll through the huge macro in that file quite quickly. However, typing in the buffer is still suboptimal. I don't know how much I'll be able to do to sort this out. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#10652: 24.0.93; font-lock very slow for C++ 2012-02-26 9:47 ` Chong Yidong 2012-03-01 19:36 ` Alan Mackenzie 2012-03-02 22:27 ` Alan Mackenzie @ 2012-03-16 14:19 ` Alan Mackenzie 2 siblings, 0 replies; 14+ messages in thread From: Alan Mackenzie @ 2012-03-16 14:19 UTC (permalink / raw) To: Chong Yidong; +Cc: Helmut Eller, 10652 Hello, Yidong, Helmut. On Sun, Feb 26, 2012 at 05:47:25PM +0800, Chong Yidong wrote: > Helmut Eller <eller.helmut@gmail.com> writes: > > Font lock is extremely slow in this file: > > http://hg.openjdk.java.net/jdk7/jdk7/hotspot/raw-file/b92c45f2bc75/src/share/vm/runtime/globals.hpp > > Download the file and open it with emacs -Q globals.hpp. Then > > scroll around in the file to see how slow it is. > I got Emacs into an uninterruptible loop while scrolling through the > buffer :-( > Looks like a regression against Emacs 23's CC mode, which handles the > file just fine. Alan, could you investigate? Thanks. I've just committed revision #107615, which solves the slow scrolling problem. Typing "electric" characters (e.g. comma) into the buffer is still slower than I'd like, but is tolerable. I don't intend doing any more optimisation before the next pretest (or release :-). -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#10652: font-lock very slow for C++ 2012-01-30 11:15 bug#10652: 24.0.93; font-lock very slow for C++ Helmut Eller 2012-02-26 9:47 ` Chong Yidong @ 2012-03-14 9:45 ` Toon Claes 2012-03-16 10:18 ` bug#10652: Recursive loop in alloc.c [ Was: font-lock very slow for C++ ] Alan Mackenzie [not found] ` <20120316101838.GB3439@acm.acm> 2012-03-16 14:24 ` bug#10652: 24.0.93; font-lock very slow for C++ Alan Mackenzie 2012-03-28 7:07 ` bug#10652: " Toon Claes 3 siblings, 2 replies; 14+ messages in thread From: Toon Claes @ 2012-03-14 9:45 UTC (permalink / raw) To: 10652 [-- Attachment #1: Type: text/plain, Size: 833 bytes --] I'm also having trouble with some cpp files. I've got one file (572 lines, 18560 bytes), that always causes emacs 24 to hang. Emacs 23.3.1 handles this file just fine. I am using emacs from git: commit 6ba3ea4d2625fac8b5fb839f11eeb074d699687e Author: Christopher Schmidt <christopher@ch.ristopher.com> Date: Mon Mar 12 01:31:44 2012 +0800 * ibuffer.el (ibuffer-redisplay): Remove gratuitous error. When GDB was hanging I stopped the process with GDB, with this backtrace: http://pastebin.com/ssB96ue4 I'm not familiar with the emacs source code, but I do not know this is normal. If I can help investigation the problem more in detail, let me know. Unfortunately I am not allowed to share the source file with you. Also I've tried to decrease font-lock-maximum-decoration to 1, but this didn't have effect. [-- Attachment #2: Type: text/html, Size: 1117 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#10652: Recursive loop in alloc.c [ Was: font-lock very slow for C++ ] 2012-03-14 9:45 ` bug#10652: " Toon Claes @ 2012-03-16 10:18 ` Alan Mackenzie [not found] ` <20120316101838.GB3439@acm.acm> 1 sibling, 0 replies; 14+ messages in thread From: Alan Mackenzie @ 2012-03-16 10:18 UTC (permalink / raw) To: Toon Claes; +Cc: 10652 Hello, Emacs and Toon. I've retitled this bug to clarify what it's about. -- Alan Mackenzie (Nuremberg, Germany). On Wed, Mar 14, 2012 at 11:45:14AM +0200, Toon Claes wrote: > I'm also having trouble with some cpp files. > I've got one file > (572 lines, 18560 bytes), that always causes emacs 24 to hang. Emacs > 23.3.1 handles this file just fine. > I am using emacs from git: > commit 6ba3ea4d2625fac8b5fb839f11eeb074d699687e > Author: Christopher > Schmidt <christopher@ch.ristopher.com> > Date: Mon Mar 12 01:31:44 2012 > +0800 > * ibuffer.el (ibuffer-redisplay): Remove gratuitous error. > When GDB was hanging I stopped the process with GDB, with this > backtrace: > http://pastebin.com/ssB96ue4 > I'm not familiar with the > emacs source code, but I do not know this is normal. > If I can help > investigation the problem more in detail, let me know. > Unfortunately I > am not allowed to share the source file with you. > Also I've tried to > decrease font-lock-maximum-decoration to 1, but this didn't have effect. > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <20120316101838.GB3439@acm.acm>]
* bug#10652: Recursive loop in alloc.c [ Was: font-lock very slow for C++ ] [not found] ` <20120316101838.GB3439@acm.acm> @ 2012-03-16 10:34 ` Andreas Schwab 0 siblings, 0 replies; 14+ messages in thread From: Andreas Schwab @ 2012-03-16 10:34 UTC (permalink / raw) To: Alan Mackenzie; +Cc: Toon Claes, 10652 Alan Mackenzie <acm@muc.de> writes: > I've retitled this bug to clarify what it's about. That's just the garbage collector, perfectly normal. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#10652: 24.0.93; font-lock very slow for C++ 2012-01-30 11:15 bug#10652: 24.0.93; font-lock very slow for C++ Helmut Eller 2012-02-26 9:47 ` Chong Yidong 2012-03-14 9:45 ` bug#10652: " Toon Claes @ 2012-03-16 14:24 ` Alan Mackenzie 2012-03-28 7:07 ` bug#10652: " Toon Claes 3 siblings, 0 replies; 14+ messages in thread From: Alan Mackenzie @ 2012-03-16 14:24 UTC (permalink / raw) To: 10652-done Fixed. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#10652: font-lock very slow for C++ 2012-01-30 11:15 bug#10652: 24.0.93; font-lock very slow for C++ Helmut Eller ` (2 preceding siblings ...) 2012-03-16 14:24 ` bug#10652: 24.0.93; font-lock very slow for C++ Alan Mackenzie @ 2012-03-28 7:07 ` Toon Claes 2012-03-29 9:35 ` Alan Mackenzie 3 siblings, 1 reply; 14+ messages in thread From: Toon Claes @ 2012-03-28 7:07 UTC (permalink / raw) To: Alan Mackenzie, 10652 [-- Attachment #1: Type: text/plain, Size: 281 bytes --] Hello Alan, Your changes indeed help. Still it happens emacs completely hangs when isearching. So I do not really agree the bug is fixed. I can (but not really allowed to) send you the cpp file which causes trouble. If you agree to not distribute it? Regards, Toon [-- Attachment #2: Type: text/html, Size: 487 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#10652: font-lock very slow for C++ 2012-03-28 7:07 ` bug#10652: " Toon Claes @ 2012-03-29 9:35 ` Alan Mackenzie 2012-03-29 19:46 ` Toon Claes 0 siblings, 1 reply; 14+ messages in thread From: Alan Mackenzie @ 2012-03-29 9:35 UTC (permalink / raw) To: Toon Claes; +Cc: 10652 Hi, Toon. On Wed, Mar 28, 2012 at 09:07:23AM +0200, Toon Claes wrote: > Hello Alan, > Your changes indeed help. > Still it happens emacs > completely hangs when isearching. So I do not really agree the bug is > fixed. Sorry about that! Can I assume (i) You've already tried this, starting Emacs with Emacs -Q? (ii) Youre using the latest version of Emacs 24? Searching and C++ Mode are, as far as I know, completely orthogonal. Before going any further, could you please try switching the file into fundamental mode (with M-x fundamental-mode) and tell me if the search still hangs. Thanks! [ .... ] > Regards, > Toon -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#10652: font-lock very slow for C++ 2012-03-29 9:35 ` Alan Mackenzie @ 2012-03-29 19:46 ` Toon Claes 2012-03-29 22:00 ` Alan Mackenzie 0 siblings, 1 reply; 14+ messages in thread From: Toon Claes @ 2012-03-29 19:46 UTC (permalink / raw) To: Alan Mackenzie; +Cc: 10652@debbugs.gnu.org Hi Alan, About: (i) yes I've tried that, emacs -Q didn't make a difference (ii) I am using emacs from git, commit 2ac37884107bd4e78bb… Should I get it from the bazaar repo? (iii) I know font-lock has nothing to do with isearch. When I disable font-lock-mode for the buffer, isearch does not hang. So the issue isn't isearch. Sorry I created some confusion in previous mail. Toon On 29 Mar 2012, at 11:35, Alan Mackenzie wrote: > Hi, Toon. > > On Wed, Mar 28, 2012 at 09:07:23AM +0200, Toon Claes wrote: > > >> Hello Alan, > >> Your changes indeed help. > >> Still it happens emacs >> completely hangs when isearching. So I do not really agree the bug is >> fixed. > > Sorry about that! Can I assume > (i) You've already tried this, starting Emacs with Emacs -Q? > (ii) Youre using the latest version of Emacs 24? > > Searching and C++ Mode are, as far as I know, completely orthogonal. > Before going any further, could you please try switching the file into > fundamental mode (with M-x fundamental-mode) and tell me if the search > still hangs. Thanks! > > [ .... ] > >> Regards, > >> Toon > > -- > Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#10652: font-lock very slow for C++ 2012-03-29 19:46 ` Toon Claes @ 2012-03-29 22:00 ` Alan Mackenzie 2012-04-02 7:48 ` Toon Claes 0 siblings, 1 reply; 14+ messages in thread From: Alan Mackenzie @ 2012-03-29 22:00 UTC (permalink / raw) To: Toon Claes; +Cc: 10652@debbugs.gnu.org Hello, Toon. On Thu, Mar 29, 2012 at 09:46:03PM +0200, Toon Claes wrote: > Hi Alan, > About: > (i) yes I've tried that, emacs -Q didn't make a difference Worth knowing > (ii) I am using emacs from git, commit 2ac37884107bd4e78bb… Should I > get it from the bazaar repo? I'm not familiar with the git repository. If the revision is recent (within the last week or two or three) it should be OK. I just wanted to check you weren't using a 6-month old version. > (iii) I know font-lock has nothing to do with isearch. When I disable > font-lock-mode for the buffer, isearch does not hang. So the issue > isn't isearch. Sorry I created some confusion in previous mail. OK. What I suspect is that the isearch works fine, then the fontification hangs before the screen can redisplay. How long does it hang for? Any chance you could perhaps leave it hanging over lunchtime, or perhaps even overnight to see if it might just be _very_ slow. Could you perhaps try disabling font-lock, doing the isearch, then enabling font-lock again. Does it then still hang, or does it come up OK? Lastly, is there anything unusual about your test file. Perhaps long regions of text which contain no semicolons or maybe no braces? Or maybe hundreds of macro definitions one after the other, something like that? > Toon -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#10652: font-lock very slow for C++ 2012-03-29 22:00 ` Alan Mackenzie @ 2012-04-02 7:48 ` Toon Claes 0 siblings, 0 replies; 14+ messages in thread From: Toon Claes @ 2012-04-02 7:48 UTC (permalink / raw) To: Alan Mackenzie; +Cc: 10652 [-- Attachment #1: Type: text/plain, Size: 1583 bytes --] Hi Alan, emacs hangs for hours. Luckily it only used one of my 4 processor cores, so I could leave it loading in the background. This is what I've done: Open the file, in c++-mode, and scroll to end-of-buffer (M->). The mouse cursor starts spinning, but the end of buffer is not shown. When I press C-g three times, the end of the buffer is shown. The fontification looks correct. When I go back to beginning-of-buffer, same problem. When I press M->, M-< several times, I cannot recover with C-g and I need to kill emacs:-( isearch works fine with font-lock-mode disabled. Even, depending on the position in the buffer, it happens the command M-x font-lock-mode gives the spinning mouse cursor. Again 3x C-g solves this. So I can say pretty sure, font-lock-mode is causing the "delay". I've tested again with the bazaar version of last friday. My test file contains something like this: int ClassName::MethodAbc(void) { SOME_PRETEST_MACRO; return TranslateResult(LibFunctionAbc(m_Member)); } And this repeated for something like 20 times (of course with different names, and with different parameters). The macro is something like: #define SOME_PRETEST_MACRO if (!Ready()) return -1; With this test file, I could easily reproduce the problem. I hope this can help investigating the issue. Toon On 2012-03-30 00:00, Alan Mackenzie wrote: > Hello, Toon. > > On Thu, Mar 29, 2012 at 09:46:03PM +0200, Toon Claes wrote: > >> Hi Alan, > >> About: (i) yes I've tried that, emacs -Q didn't make a difference > > Worth knowing [-- Attachment #2: Type: text/html, Size: 4145 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2012-04-02 7:48 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-01-30 11:15 bug#10652: 24.0.93; font-lock very slow for C++ Helmut Eller
2012-02-26 9:47 ` Chong Yidong
2012-03-01 19:36 ` Alan Mackenzie
2012-03-02 22:27 ` Alan Mackenzie
2012-03-16 14:19 ` Alan Mackenzie
2012-03-14 9:45 ` bug#10652: " Toon Claes
2012-03-16 10:18 ` bug#10652: Recursive loop in alloc.c [ Was: font-lock very slow for C++ ] Alan Mackenzie
[not found] ` <20120316101838.GB3439@acm.acm>
2012-03-16 10:34 ` Andreas Schwab
2012-03-16 14:24 ` bug#10652: 24.0.93; font-lock very slow for C++ Alan Mackenzie
2012-03-28 7:07 ` bug#10652: " Toon Claes
2012-03-29 9:35 ` Alan Mackenzie
2012-03-29 19:46 ` Toon Claes
2012-03-29 22:00 ` Alan Mackenzie
2012-04-02 7:48 ` Toon Claes
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).