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

Previous Next

Full log

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

Previous Next

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