GNU bug report logs - #42490
Emacs is very slow when navigating into a specific C++ file

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 42490 in the body.
You can then email your comments to 42490 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Olivier Scalbert <olivier.scalbert <at> algosyn.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Emacs is very slow when navigating into a specific C++ file
Date: Thu, 23 Jul 2020 09:45:18 +0200

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

Message #8 received at 42490 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: Olivier Scalbert <olivier.scalbert <at> algosyn.com>
Cc: Alan Mackenzie <acm <at> muc.de>, 42490 <at> debbugs.gnu.org
Subject: bug#42490: Emacs is very slow when navigating into a specific C++
 file 
Date: Fri, 24 Jul 2020 18:46:45 +0200

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.

Message #11 received at 42490 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Mattias Engdegård <mattiase <at> acm.org>,
 Olivier Scalbert <olivier.scalbert <at> algosyn.com>
Cc: 42490 <at> debbugs.gnu.org
Subject: Re: bug#42490: Emacs is very slow when navigating into a specific
 C++ file
Date: Fri, 24 Jul 2020 19:24:50 +0000

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

Message #14 received at 42490 <at> debbugs.gnu.org (full text, mbox):

From: Olivier Scalbert <olivier.scalbert <at> algosyn.com>
To: Alan Mackenzie <acm <at> muc.de>, Mattias Engdegård
 <mattiase <at> acm.org>
Cc: 42490 <at> debbugs.gnu.org
Subject: Re: bug#42490: Emacs is very slow when navigating into a specific C++
 file
Date: Fri, 24 Jul 2020 21:34:51 +0200

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 <at> 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.
>

Message #17 received at 42490 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Olivier Scalbert <olivier.scalbert <at> algosyn.com>
Cc: Mattias Engdegård <mattiase <at> acm.org>,
 42490 <at> debbugs.gnu.org, acm <at> muc.de
Subject: Re: bug#42490: Emacs is very slow when navigating into a specific
 C++ file
Date: Mon, 21 Sep 2020 09:06:39 +0000

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

Message #20 received at 42490 <at> debbugs.gnu.org (full text, mbox):

From: Olivier Scalbert <olivier.scalbert <at> algosyn.com>
To: Alan Mackenzie <acm <at> muc.de>
Cc: Mattias Engdegård <mattiase <at> acm.org>,
 42490 <at> debbugs.gnu.org
Subject: Re: bug#42490: Emacs is very slow when navigating into a specific C++
 file
Date: Mon, 21 Sep 2020 19:29:28 +0200

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 <at> 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.

Message #25 received at 42490 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Olivier Scalbert <olivier.scalbert <at> algosyn.com>
Cc: Mattias Engdegård <mattiase <at> acm.org>,
 42490 <at> debbugs.gnu.org
Subject: Re: bug#42490: Emacs is very slow when navigating into a specific
 C++ file
Date: Tue, 22 Sep 2020 10:03:41 +0000

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.