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

[Olivier Scalbert <olivier.scalbert@algosyn.com>]

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