Reported by: Sam Varshavchik <sam.varshavchik <at> gmail.com>
Date: Mon, 28 Jul 2014 22:39:01 UTC
Severity: normal
Found in versions 27.0.50, 24.3
Done: Alan Mackenzie <acm <at> muc.de>
Bug is archived. No further changes may be made.
View this message in rfc822 format
From: Alan Mackenzie <acm <at> muc.de> To: Stefan Kangas <stefan <at> marxist.se> Cc: 18134 <at> debbugs.gnu.org, Sam Varshavchik <sam.varshavchik <at> gmail.com> Subject: bug#18134: 24.3; Doxygen comments trigger anomalous C++ major mode behavior Date: Sat, 19 Oct 2019 16:13:05 +0000
Hello, Stefan and Sam. On Mon, Oct 07, 2019 at 00:42:46 +0200, Stefan Kangas wrote: > found 27.0.50 > thanks > Sam Varshavchik <sam.varshavchik <at> gmail.com> writes: > > I am seeing anomalous behavior in C++ major mode that's triggered by > > long, but not excessively long -- only a few hundred lines -- Doxygen-style > > comments. > > Cursor navigation at the end of the Doxygen comment block in the > > following file (just before the first typedef), and trying to add some > > additional text there, results in 3-5 seconds' worth of delays for > > nearly typed character. > > Highlighting the entire Doxygen comment block: M-x indent-region takes > > several minutes (!) with emacs consuming 100% CPU. > [Snipped a long C++ example file here.] > I can reproduce both issues on current master using the provided example > file. > 1. Editing is very slow after the Doxygen comment block. > 2. Opening the example file under "emacs -Q", pressing C-x h TAB takes > several minutes and sees the emacs process consume 100 % CPU (on one > core at least). Yes. Some optimisation is needed in c-crosses-statement-barrier-p for large blocks of comments. Please try out this patch, and let me know if anything untoward happens: diff -r d84523ed901e cc-engine.el --- a/cc-engine.el Sat Oct 12 08:55:31 2019 +0000 +++ b/cc-engine.el Sat Oct 19 16:06:23 2019 +0000 @@ -1474,10 +1474,13 @@ (progn (if (setq lit-start (c-literal-start from)) ; Have we landed in a string/comment? (goto-char lit-start)) - (c-backward-syntactic-ws) ; ? put a limit here, maybe? + (c-backward-syntactic-ws (c-point 'bopl)) (setq vsemi-pos (point)) (c-at-vsemi-p)))) (throw 'done vsemi-pos)) + ((progn (c-forward-syntactic-ws to) + (>= (point) to)) + (throw 'done nil)) ;; In a string/comment? ((setq lit-range (c-literal-limits from)) (goto-char (cdr lit-range))) > Using the profiler during step 2 gives me: > >- command-execute 59856 97% > > - call-interactively 59856 97% > > - funcall-interactively 59827 97% > > - c-indent-line-or-region 59820 97% > > - c-indent-region 59819 97% > > - c-guess-basic-syntax 59809 97% > > - c-beginning-of-statement-1 39327 63% > > - c-crosses-statement-barrier-p 39105 63% <==== > > - c-backward-sws 22222 36% > > + c-beginning-of-macro 492 0% > > #<compiled 0x1579d1980ead> 1 0% > > c-literal-limits 9508 15% > > c-literal-start 6228 10% > > + c-at-macro-vsemi-p 217 0% > > + c-backward-sws 61 0% > > + c-at-macro-vsemi-p 16 0% > > + c-beginning-of-macro 10 0% > > - c-just-after-func-arglist-p 19872 32% > > - c-beginning-of-statement-1 19872 32% > > - c-crosses-statement-barrier-p 19795 32% > > - c-backward-sws 11424 18% > > + c-beginning-of-macro 287 0% > > #<compiled 0x1579d1980ead> 2 0% > > c-literal-limits 4707 7% > > c-literal-start 3095 5% > > + c-at-macro-vsemi-p 121 0% > > + c-backward-sws 17 0% > > c-beginning-of-macro 2 0% > > c-at-macro-vsemi-p 1 0% > > + c-looking-at-inexpr-block 1 0% > > + c-backward-sws 202 0% > > + c-back-over-member-initializers 106 0% > > + c-determine-limit 103 0% > > + c-parse-state 61 0% > > + c-looking-at-decl-block 55 0% > > + c-looking-at-inexpr-block 19 0% > > + c-syntactic-skip-backward 13 0% > > + c-back-over-member-initializer-braces 4 0% > > + c-beginning-of-decl-1 4 0% > > + c-in-literal 3 0% > > + c-at-macro-vsemi-p 1 0% > > + c-inside-bracelist-p 1 0% > > + c-at-statement-start-p 1 0% > > + c-indent-line 9 0% > > + execute-extended-command 7 0% > > - byte-code 29 0% > > + read-extended-command 29 0% > >+ ... 1784 2% > (Quoted above so Gmail doesn't mess it up...) > Best regards, > Stefan Kangas -- Alan Mackenzie (Nuremberg, Germany).
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.