bug#30849: 27.0.50; CC-mode: very slow when parsing big C array initializer

bug#30849: 27.0.50; CC-mode: very slow when parsing big C array initializer

[David Welch]

[-- Attachment #1: Type: text/plain, Size: 5398 bytes --]


Run 'emacs -Q bar.c' (this file is attached)
Goto a line inside the initializer e.g. 'M-x goto-line RET 9522'
emacs will hang for ~50 seconds on a 100% cpu on a Intel i7 @ 3.40GHz.

This bug seems to be introduced by

commit d3090a3a3e22c4b0f4e0e833942f5942eb392c51 (HEAD, refs/bisect/bad)
Author: Alan Mackenzie <acm@muc.de>
Date:   Fri Feb 2 20:46:35 2018 +0000

    CC Mode: Fix an enum intro being parsed as defun-block-intro
    
    * lisp/progmodes/cc-engine.el (c-inside-bracelist-p): Return a bufpos rather
    than t for the enum case.
    (c-add-stmt-syntax, c-guess-continued-construct): Replace
    c-looking-at-or-maybe-in-bracelist by c-inside-bracelist-p, since the former
    does not recognize enum brace lists, but the latter does.
    
    * lisp/progmodes/cc-fonts.el (c-get-fontification-context): Replace
    c-looking-at-or-maybe-in-bracelist by c-inside-bracelist-p.

I generated a profile and 95% of time is spent in c-inside-bracelist-p
called from c-get-fontification-context.


In GNU Emacs 27.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.22.25)
 of 2018-03-17 built on lgw01-amd64-055
Windowing system distributor 'The X.Org Foundation', version 11.0.11803000
System Description: Ubuntu 17.10

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Configured using:
 'configure --build=x86_64-linux-gnu --prefix=/usr
 '--includedir=${prefix}/include' '--mandir=${prefix}/share/man'
 '--infodir=${prefix}/share/info' --sysconfdir=/etc --localstatedir=/var
 --disable-silent-rules '--libdir=${prefix}/lib/x86_64-linux-gnu'
 '--libexecdir=${prefix}/lib/x86_64-linux-gnu' --disable-maintainer-mode
 --disable-dependency-tracking --prefix=/usr --sharedstatedir=/var/lib
 --program-suffix=-snapshot --with-modules=yes --with-x=yes
 --with-x-toolkit=gtk3 --with-xwidgets=yes 'CFLAGS=-g -O2
 -fdebug-prefix-map=/build/emacs-snapshot-lB2ym1/emacs-snapshot-94474=. -fstack-protector-strong
 -Wformat -Werror=format-security' 'CPPFLAGS=-Wdate-time
 -D_FORTIFY_SOURCE=2' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro''

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS NOTIFY
LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 MODULES THREADS XWIDGETS LIBSYSTEMD LCMS2

Important settings:
  value of $LANG: en_GB.UTF-8
  locale-coding-system: utf-8-unix

Major mode: C/*l

Minor modes in effect:
  diff-auto-refine-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t
  abbrev-mode: t

Load-path shadows:
/usr/share/emacs/site-lisp/llvm-4.0/tablegen-mode hides /usr/share/emacs/site-lisp/llvm-5.0/tablegen-mode
/usr/share/emacs/site-lisp/llvm-4.0/emacs hides /usr/share/emacs/site-lisp/llvm-5.0/emacs
/usr/share/emacs/site-lisp/llvm-4.0/llvm-mode hides /usr/share/emacs/site-lisp/llvm-5.0/llvm-mode
/usr/share/emacs/site-lisp/rst hides /usr/share/emacs/27.0.50/lisp/textmodes/rst
/usr/share/emacs/site-lisp/dictionaries-common/flyspell hides /usr/share/emacs/27.0.50/lisp/textmodes/flyspell
/usr/share/emacs/site-lisp/dictionaries-common/ispell hides /usr/share/emacs/27.0.50/lisp/textmodes/ispell

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
format-spec rfc822 mml mml-sec password-cache epa derived epg epg-config
gnus-util rmail rmail-loaddefs mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils vc-git diff-mode easy-mmode map
seq byte-opt gv bytecomp byte-compile cconv cc-mode cc-fonts easymenu
cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs
cl-loaddefs cl-lib elec-pair time-date mule-util tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote dbusbind inotify lcms2 dynamic-setting system-font-setting
font-render-setting xwidget-internal move-toolbar gtk x-toolkit x
multi-tty make-network-process emacs)

Memory information:
((conses 16 119309 10422)
 (symbols 48 22894 1)
 (miscs 40 83 136)
 (strings 32 35675 2207)
 (string-bytes 1 1073774)
 (vectors 16 18053)
 (vector-slots 8 536564 11124)
 (floats 8 57 70)
 (intervals 56 417 1)
 (buffers 992 13))













[-- Attachment #2: bar.c.gz --]
[-- Type: application/gzip, Size: 3466 bytes --]

[-- Attachment #3: bar-slow.profile.gz --]
[-- Type: application/gzip, Size: 1040 bytes --]

[-- Attachment #4: bar-fast.profile.gz --]
[-- Type: application/gzip, Size: 992 bytes --]

bug#30849: 27.0.50; CC-mode: very slow when parsing big C array initializer

[Alan Mackenzie]

Hello, David.

On Sun, Mar 18, 2018 at 18:04:55 +0000, David Welch wrote:

> Run 'emacs -Q bar.c' (this file is attached)
> Goto a line inside the initializer e.g. 'M-x goto-line RET 9522'
> emacs will hang for ~50 seconds on a 100% cpu on a Intel i7 @ 3.40GHz.

Yes.  This isn't good.

> This bug seems to be introduced by

> commit d3090a3a3e22c4b0f4e0e833942f5942eb392c51 (HEAD, refs/bisect/bad)
> Author: Alan Mackenzie <acm@muc.de>
> Date:   Fri Feb 2 20:46:35 2018 +0000

>     CC Mode: Fix an enum intro being parsed as defun-block-intro
>     
>     * lisp/progmodes/cc-engine.el (c-inside-bracelist-p): Return a bufpos rather
>     than t for the enum case.
>     (c-add-stmt-syntax, c-guess-continued-construct): Replace
>     c-looking-at-or-maybe-in-bracelist by c-inside-bracelist-p, since the former
>     does not recognize enum brace lists, but the latter does.
>     
>     * lisp/progmodes/cc-fonts.el (c-get-fontification-context): Replace
>     c-looking-at-or-maybe-in-bracelist by c-inside-bracelist-p.

> I generated a profile and 95% of time is spent in c-inside-bracelist-p
> called from c-get-fontification-context.

Thanks for taking the trouble to report this, and thanks for researching
the cause.

I think this bug is a duplicate of bug #30367, for which I've just
committed commit 16559146f9db1b36d5e8b6c92edb5bb36fafdb85 to savannah.
(Thanks for giving me a nudge, here.)

> In GNU Emacs 27.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.22.25)
>  of 2018-03-17 built on lgw01-amd64-055
> Windowing system distributor 'The X.Org Foundation', version 11.0.11803000
> System Description: Ubuntu 17.10

Seeing as how you're using master, would you please pull this change
into your copy of the repository, and see if you agree with me that it
fixes this bug.

Bear in mind that in such an unusual source file (with a ~17,500 line
array initialisation), CC Mode is going to take some time to analyse
things.  But taking nearly a minute to draw a screen is outside the
bounds of acceptability.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#30849: 27.0.50; CC-mode: very slow when parsing big C array initializer

[David Welch]

[-- Attachment #1: Type: text/plain, Size: 2405 bytes --]

> Seeing as how you're using master, would you please pull this change
> into your copy of the repository, and see if you agree with me that it
> fixes this bug.

>

Yes, thanks. That fixes the slow down for me.

________________________________
From: Alan Mackenzie <acm@muc.de>
Sent: 20 March 2018 19:48
To: David Welch
Cc: 30849@debbugs.gnu.org
Subject: Re: bug#30849: 27.0.50; CC-mode: very slow when parsing big C array initializer

Hello, David.

On Sun, Mar 18, 2018 at 18:04:55 +0000, David Welch wrote:

> Run 'emacs -Q bar.c' (this file is attached)
> Goto a line inside the initializer e.g. 'M-x goto-line RET 9522'
> emacs will hang for ~50 seconds on a 100% cpu on a Intel i7 @ 3.40GHz.

Yes.  This isn't good.

> This bug seems to be introduced by

> commit d3090a3a3e22c4b0f4e0e833942f5942eb392c51 (HEAD, refs/bisect/bad)
> Author: Alan Mackenzie <acm@muc.de>
> Date:   Fri Feb 2 20:46:35 2018 +0000

>     CC Mode: Fix an enum intro being parsed as defun-block-intro
>
>     * lisp/progmodes/cc-engine.el (c-inside-bracelist-p): Return a bufpos rather
>     than t for the enum case.
>     (c-add-stmt-syntax, c-guess-continued-construct): Replace
>     c-looking-at-or-maybe-in-bracelist by c-inside-bracelist-p, since the former
>     does not recognize enum brace lists, but the latter does.
>
>     * lisp/progmodes/cc-fonts.el (c-get-fontification-context): Replace
>     c-looking-at-or-maybe-in-bracelist by c-inside-bracelist-p.

> I generated a profile and 95% of time is spent in c-inside-bracelist-p
> called from c-get-fontification-context.

Thanks for taking the trouble to report this, and thanks for researching
the cause.

I think this bug is a duplicate of bug #30367, for which I've just
committed commit 16559146f9db1b36d5e8b6c92edb5bb36fafdb85 to savannah.
(Thanks for giving me a nudge, here.)

> In GNU Emacs 27.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.22.25)
>  of 2018-03-17 built on lgw01-amd64-055
> Windowing system distributor 'The X.Org Foundation', version 11.0.11803000
> System Description: Ubuntu 17.10



Bear in mind that in such an unusual source file (with a ~17,500 line
array initialisation), CC Mode is going to take some time to analyse
things.  But taking nearly a minute to draw a screen is outside the
bounds of acceptability.

--
Alan Mackenzie (Nuremberg, Germany).

[-- Attachment #2: Type: text/html, Size: 3863 bytes --]