unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Stefan Kangas <stefan@marxist.se>
Cc: 18134@debbugs.gnu.org, Sam Varshavchik <sam.varshavchik@gmail.com>
Subject: bug#18134: 24.3; Doxygen comments trigger anomalous C++ major mode behavior
Date: Sat, 19 Oct 2019 16:13:05 +0000	[thread overview]
Message-ID: <20191019161305.GB7911@ACM> (raw)
In-Reply-To: <CADwFkm=6UZKRZ3zaDqiTPD0S52XGvGTrPowugw-3HruLNbti_A@mail.gmail.com>

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@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).





  parent reply	other threads:[~2019-10-19 16:13 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-28 12:47 bug#18134: 24.3; Doxygen comments trigger anomalous C++ major mode behavior Sam Varshavchik
2019-10-06 22:42 ` Stefan Kangas
2019-10-07 18:51   ` Alan Mackenzie
2019-10-07 19:04     ` Stefan Kangas
2019-10-19 16:13   ` Alan Mackenzie [this message]
2019-10-20 13:36     ` Stefan Kangas
2019-10-20 17:04       ` Alan Mackenzie
2019-10-20 23:12       ` Sam Varshavchik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191019161305.GB7911@ACM \
    --to=acm@muc.de \
    --cc=18134@debbugs.gnu.org \
    --cc=sam.varshavchik@gmail.com \
    --cc=stefan@marxist.se \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).