bug#42490: Emacs is very slow when navigating into a specific C++ file

bug#42490: Emacs is very slow when navigating into a specific C++ file

[Olivier Scalbert]

Hi !

With Emacs 26.1 or 26.3 on my Xeon Debian box, I have some problems with 
the following C++ file: 
https://github.com/mamedev/mame/blob/master/src/devices/cpu/z80/z80.cpp 
(which is part of the Mame project).

When I open it and press several times the "page down" key, Emacs seems 
to hang. In fact 100% of the cpu is consumed during 10 to 15 seconds. 
Then it works well.

My Emacs config is nearly empty.

The C++ code is a little special as is contains lot of macros, but I can
open it and navigate into it without problem with vim or VSCode.

If I turn off syntax highlighting, it run smoother.

Thanks for the help !

Olivier



In GNU Emacs 26.1 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.5)
of 2019-09-23, modified by Debian built on x86-grnet-01
Windowing system distributor 'The X.Org Foundation', version 11.0.12004000
System Description: Debian GNU/Linux 10 (buster)

Recent messages:
Loading /etc/emacs/site-start.d/50gnugo.el (source)...done
Loading /etc/emacs/site-start.d/50latex-cjk-common.el (source)...
Loading /usr/share/emacs/site-lisp/latex-cjk-common/cjk-enc.el 
(source)...done
Loading /etc/emacs/site-start.d/50latex-cjk-common.el (source)...done
Loading /etc/emacs/site-start.d/50latex-cjk-thai.el (source)...done
Loading /etc/emacs/site-start.d/50openscad.el (source)...done
Loading /etc/emacs/site-start.d/50python-docutils.el (source)...done
Loading /etc/emacs/site-start.d/50texlive-lang-english.el (source)...done
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list... [2 times]

Configured using:
'configure --build x86_64-linux-gnu --prefix=/usr
--sharedstatedir=/var/lib --libexecdir=/usr/lib
--localstatedir=/var/lib --infodir=/usr/share/info
--mandir=/usr/share/man --enable-libsystemd --with-pop=yes
--enable-locallisppath=/etc/emacs:/usr/local/share/emacs/26.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/26.1/site-lisp:/usr/share/emacs/site-lisp 

--with-sound=alsa --without-gconf --with-mailutils --build
x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib
--libexecdir=/usr/lib --localstatedir=/var/lib
--infodir=/usr/share/info --mandir=/usr/share/man --enable-libsystemd
--with-pop=yes
--enable-locallisppath=/etc/emacs:/usr/local/share/emacs/26.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/26.1/site-lisp:/usr/share/emacs/site-lisp 

--with-sound=alsa --without-gconf --with-mailutils --with-x=yes
--with-x-toolkit=gtk3 --with-toolkit-scroll-bars 'CFLAGS=-g -O2
-fdebug-prefix-map=/build/emacs-StqULU/emacs-26.1+1=. 
-fstack-protector-strong
-Wformat -Werror=format-security -Wall' 'CPPFLAGS=-Wdate-time
-D_FORTIFY_SOURCE=2' LDFLAGS=-Wl,-z,relro'

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

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

Major mode: Lisp Interaction

Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
electric-indent-mode: t
mouse-wheel-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
column-number-mode: t
line-number-mode: t
transient-mark-mode: t

Load-path shadows:
/usr/share/emacs/site-lisp/rst hides 
/usr/share/emacs/26.1/lisp/textmodes/rst
/usr/share/emacs/site-lisp/latex-cjk-thai/thai-word hides 
/usr/share/emacs/26.1/lisp/language/thai-word

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
format-spec rfc822 mml mml-sec epa derived epg 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 elec-pair solarized-dark-theme solarized
color dash finder-inf info package easymenu epg-config url-handlers
url-parse auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
password-cache url-vars seq byte-opt gv bytecomp byte-compile cconv
cl-loaddefs cl-lib 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 move-toolbar gtk x-toolkit x multi-tty
make-network-process emacs)

Memory information:
((conses 16 282823 12891)
(symbols 48 28411 2)
(miscs 40 50 76)
(strings 32 78429 1210)
(string-bytes 1 1842487)
(vectors 16 21905)
(vector-slots 8 611952 8270)
(floats 8 277 315)
(intervals 56 282 0)
(buffers 992 12))

bug#42490: Emacs is very slow when navigating into a specific C++ file

[Mattias Engdegård]

Hello Olivier,

Thanks for the report! Could you try Emacs 27 (or git master), building from source if necessary? Those versions should be slightly faster, although the response time is probably well below acceptable.

If we distill the essentials of your file to some sort of benchmark, we might end up with:

(with-temp-buffer
  (c++-mode)
  (dotimes (_ 1000)
    (insert "OP(ed,b0) { ldir(); } /* LDIR */\n"))
  (garbage-collect)
  (let ((t0 (current-time)))
    (font-lock-ensure (point-min) (point-max))
    (time-to-seconds (time-since t0))))

Emacs 26.3 runs it in 11.9 s on this old lappy, but Emacs 27 does it in 3.3 s. This is a clear improvement but we should be able to do better. Alan may have a feeling for where the cycles are spent.

bug#42490: Emacs is very slow when navigating into a specific C++ file

[Alan Mackenzie]

Hello, Mattias and Olivier.

Firstly Olivier, thanks for taking the trouble to report the bug.

On Fri, Jul 24, 2020 at 18:46:45 +0200, Mattias Engdegård wrote:
> Hello Olivier,

> Thanks for the report! Could you try Emacs 27 (or git master), building
> from source if necessary? Those versions should be slightly faster,
> although the response time is probably well below acceptable.

> If we distill the essentials of your file to some sort of benchmark, we
> might end up with:

> (with-temp-buffer
>   (c++-mode)
>   (dotimes (_ 1000)
>     (insert "OP(ed,b0) { ldir(); } /* LDIR */\n"))
>   (garbage-collect)
>   (let ((t0 (current-time)))
>     (font-lock-ensure (point-min) (point-max))
>     (time-to-seconds (time-since t0))))

> Emacs 26.3 runs it in 11.9 s on this old lappy, but Emacs 27 does it in
> 3.3 s. This is a clear improvement but we should be able to do better.
> Alan may have a feeling for where the cycles are spent.

I've bisected CC Mode to find the critical change, and it is:

commit cc80eeb4a43d2079963de3d181002a6a6b56560d
Author: Alan Mackenzie <acm@muc.de>
Date:   Fri Apr 12 20:07:03 2019 +0000

    Analyze C++ method with & or && ref-qualifier as defun, not brace list

    Also firm up detection of beginning of brace list in
    c-looking-at-or-maybe-in-bracelist.

I have a simple benchmark which scrolls through a file, fontifying it,
and my results from this benchmark are:
(i) Before applying that patch: 53.022s.
(ii) After applying that patch:  7.039s.

I don't understand at the moment why that patch sped up scrolling in your
(Olivier's) file, but it would seem the patch is most desirable.

Unfortunately, the patch won't apply cleanly to the Emacs 26.3 sources.
It might be possible to find a sequence of patches which would do the
job.  I think (though I haven't checked) the patch will have been
included in the upcoming Emacs 27.1 release.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#42490: Emacs is very slow when navigating into a specific C++ file

[Olivier Scalbert]

Hi,

Thanks for your answer.
Unfortunately, I am out of my home, with no PC, for the week-end.
If I'll survive, I will test it next Monday. Very sorry !
;-)

Regards,

Olivier







On 7/24/20 9:24 PM, Alan Mackenzie wrote:
> Hello, Mattias and Olivier.
>
> Firstly Olivier, thanks for taking the trouble to report the bug.
>
> On Fri, Jul 24, 2020 at 18:46:45 +0200, Mattias Engdegård wrote:
>> Hello Olivier,
>> Thanks for the report! Could you try Emacs 27 (or git master), building
>> from source if necessary? Those versions should be slightly faster,
>> although the response time is probably well below acceptable.
>> If we distill the essentials of your file to some sort of benchmark, we
>> might end up with:
>> (with-temp-buffer
>>    (c++-mode)
>>    (dotimes (_ 1000)
>>      (insert "OP(ed,b0) { ldir(); } /* LDIR */\n"))
>>    (garbage-collect)
>>    (let ((t0 (current-time)))
>>      (font-lock-ensure (point-min) (point-max))
>>      (time-to-seconds (time-since t0))))
>> Emacs 26.3 runs it in 11.9 s on this old lappy, but Emacs 27 does it in
>> 3.3 s. This is a clear improvement but we should be able to do better.
>> Alan may have a feeling for where the cycles are spent.
> I've bisected CC Mode to find the critical change, and it is:
>
> commit cc80eeb4a43d2079963de3d181002a6a6b56560d
> Author: Alan Mackenzie <acm@muc.de>
> Date:   Fri Apr 12 20:07:03 2019 +0000
>
>      Analyze C++ method with & or && ref-qualifier as defun, not brace list
>
>      Also firm up detection of beginning of brace list in
>      c-looking-at-or-maybe-in-bracelist.
>
> I have a simple benchmark which scrolls through a file, fontifying it,
> and my results from this benchmark are:
> (i) Before applying that patch: 53.022s.
> (ii) After applying that patch:  7.039s.
>
> I don't understand at the moment why that patch sped up scrolling in your
> (Olivier's) file, but it would seem the patch is most desirable.
>
> Unfortunately, the patch won't apply cleanly to the Emacs 26.3 sources.
> It might be possible to find a sequence of patches which would do the
> job.  I think (though I haven't checked) the patch will have been
> included in the upcoming Emacs 27.1 release.
>

bug#42490: Emacs is very slow when navigating into a specific C++ file

[Alan Mackenzie]

Hello, Olivier.

Ping?

On Fri, Jul 24, 2020 at 21:34:51 +0200, Olivier Scalbert wrote:
> Hi,

> Thanks for your answer.
> Unfortunately, I am out of my home, with no PC, for the week-end.
> If I'll survive, I will test it next Monday. Very sorry !
> ;-)

Emacs 27.1 was released just a few weeks ago.  Maybe you're already
using it.

I think CC Mode processes the test file fast enough on 27.1, so it's
probably time to close this bug.  What do you say?

> Regards,

> Olivier







> On 7/24/20 9:24 PM, Alan Mackenzie wrote:
> > Hello, Mattias and Olivier.

> > Firstly Olivier, thanks for taking the trouble to report the bug.

> > On Fri, Jul 24, 2020 at 18:46:45 +0200, Mattias Engdegård wrote:
> >> Hello Olivier,
> >> Thanks for the report! Could you try Emacs 27 (or git master), building
> >> from source if necessary? Those versions should be slightly faster,
> >> although the response time is probably well below acceptable.
> >> If we distill the essentials of your file to some sort of benchmark, we
> >> might end up with:
> >> (with-temp-buffer
> >>    (c++-mode)
> >>    (dotimes (_ 1000)
> >>      (insert "OP(ed,b0) { ldir(); } /* LDIR */\n"))
> >>    (garbage-collect)
> >>    (let ((t0 (current-time)))
> >>      (font-lock-ensure (point-min) (point-max))
> >>      (time-to-seconds (time-since t0))))
> >> Emacs 26.3 runs it in 11.9 s on this old lappy, but Emacs 27 does it in
> >> 3.3 s. This is a clear improvement but we should be able to do better.
> >> Alan may have a feeling for where the cycles are spent.
> > I've bisected CC Mode to find the critical change, and it is:

> > commit cc80eeb4a43d2079963de3d181002a6a6b56560d
> > Author: Alan Mackenzie <acm@muc.de>
> > Date:   Fri Apr 12 20:07:03 2019 +0000

> >      Analyze C++ method with & or && ref-qualifier as defun, not brace list

> >      Also firm up detection of beginning of brace list in
> >      c-looking-at-or-maybe-in-bracelist.

> > I have a simple benchmark which scrolls through a file, fontifying it,
> > and my results from this benchmark are:
> > (i) Before applying that patch: 53.022s.
> > (ii) After applying that patch:  7.039s.

> > I don't understand at the moment why that patch sped up scrolling in your
> > (Olivier's) file, but it would seem the patch is most desirable.

> > Unfortunately, the patch won't apply cleanly to the Emacs 26.3 sources.
> > It might be possible to find a sequence of patches which would do the
> > job.  I think (though I haven't checked) the patch will have been
> > included in the upcoming Emacs 27.1 release.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#42490: Emacs is very slow when navigating into a specific C++ file

[Olivier Scalbert]

Hello Alan,

Ping reply !
;-)

I was sure I had already answered. Sorry for that. With a fresh compile 
of Emacs 27.1, it is effectively faster than before. So, for me, you can 
close the bug. Many thanks ! Regards, Olivier



On 9/21/20 11:06 AM, Alan Mackenzie wrote:
> Hello, Olivier.
>
> Ping?
>
> On Fri, Jul 24, 2020 at 21:34:51 +0200, Olivier Scalbert wrote:
>> Hi,
>> Thanks for your answer.
>> Unfortunately, I am out of my home, with no PC, for the week-end.
>> If I'll survive, I will test it next Monday. Very sorry !
>> ;-)
> Emacs 27.1 was released just a few weeks ago.  Maybe you're already
> using it.
>
> I think CC Mode processes the test file fast enough on 27.1, so it's
> probably time to close this bug.  What do you say?
>
>> Regards,
>> Olivier
>
>
>
>
>
>
>> On 7/24/20 9:24 PM, Alan Mackenzie wrote:
>>> Hello, Mattias and Olivier.
>>> Firstly Olivier, thanks for taking the trouble to report the bug.
>>> On Fri, Jul 24, 2020 at 18:46:45 +0200, Mattias Engdegård wrote:
>>>> Hello Olivier,
>>>> Thanks for the report! Could you try Emacs 27 (or git master), building
>>>> from source if necessary? Those versions should be slightly faster,
>>>> although the response time is probably well below acceptable.
>>>> If we distill the essentials of your file to some sort of benchmark, we
>>>> might end up with:
>>>> (with-temp-buffer
>>>>     (c++-mode)
>>>>     (dotimes (_ 1000)
>>>>       (insert "OP(ed,b0) { ldir(); } /* LDIR */\n"))
>>>>     (garbage-collect)
>>>>     (let ((t0 (current-time)))
>>>>       (font-lock-ensure (point-min) (point-max))
>>>>       (time-to-seconds (time-since t0))))
>>>> Emacs 26.3 runs it in 11.9 s on this old lappy, but Emacs 27 does it in
>>>> 3.3 s. This is a clear improvement but we should be able to do better.
>>>> Alan may have a feeling for where the cycles are spent.
>>> I've bisected CC Mode to find the critical change, and it is:
>>> commit cc80eeb4a43d2079963de3d181002a6a6b56560d
>>> Author: Alan Mackenzie <acm@muc.de>
>>> Date:   Fri Apr 12 20:07:03 2019 +0000
>>>       Analyze C++ method with & or && ref-qualifier as defun, not brace list
>>>       Also firm up detection of beginning of brace list in
>>>       c-looking-at-or-maybe-in-bracelist.
>>> I have a simple benchmark which scrolls through a file, fontifying it,
>>> and my results from this benchmark are:
>>> (i) Before applying that patch: 53.022s.
>>> (ii) After applying that patch:  7.039s.
>>> I don't understand at the moment why that patch sped up scrolling in your
>>> (Olivier's) file, but it would seem the patch is most desirable.
>>> Unfortunately, the patch won't apply cleanly to the Emacs 26.3 sources.
>>> It might be possible to find a sequence of patches which would do the
>>> job.  I think (though I haven't checked) the patch will have been
>>> included in the upcoming Emacs 27.1 release.

bug#42490: Emacs is very slow when navigating into a specific C++ file

[Alan Mackenzie]

Hello, Olivier.

On Mon, Sep 21, 2020 at 19:29:28 +0200, Olivier Scalbert wrote:
> Hello Alan,

> Ping reply !
> ;-)

> I was sure I had already answered. Sorry for that. With a fresh compile 
> of Emacs 27.1, it is effectively faster than before. So, for me, you can 
> close the bug. Many thanks ! Regards, Olivier

Thanks.  I've closed the bug now, as fixed in Emacs 27.1.

-- 
Alan Mackenzie (Nuremberg, Germany).